[Cuis-dev] Fwd: Re: Naming conventions
Juan Vuletich
juan at jvuletich.org
Tue Apr 28 06:29:19 PDT 2020
-------- Original Message --------
From: - Tue Apr 28 09:49:20 2020
X-Account-Key: account2
X-UIDL: UID118322-1162353124
X-Mozilla-Status: 0015
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-Path: <luchiano at gmail.com>
Delivered-To: juan at jvuletich.org
Received: from gator3294.hostgator.com by gator3294.hostgator.com with
LMTP id GPIkCE6up16TpwcADDBpFA (envelope-from <luchiano at gmail.com>) for
<juan at jvuletich.org>; Mon, 27 Apr 2020 23:17:18 -0500
Return-path: <luchiano at gmail.com>
Envelope-to: juan at jvuletich.org
Delivery-date: Mon, 27 Apr 2020 23:17:18 -0500
Received: from mail-ot1-f41.google.com ([209.85.210.41]:33940) by
gator3294.hostgator.com with esmtps
(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from
<luchiano at gmail.com>) id 1jTHgK-00288o-TO for juan at jvuletich.org; Mon,
27 Apr 2020 23:17:18 -0500
Received: by mail-ot1-f41.google.com with SMTP id 72so30403982otu.1 for
<juan at jvuletich.org>; Mon, 27 Apr 2020 21:17:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com;
s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=pXpviDmgvdtqsVE7v+Fqpfkk9Ex3XO8+6Q7HsgGu+j0=;
b=haUBwlS/HlfLgc3nyh3d8ieK1CnXXkAW1Tq1uiU0L9aGXfeOzI3qUHUrSdJE3YoElV
dA0Tf1EDsf8TarVY13G4OnbaH4KRy1uBK2p2Dy1/1/h9sGhYf98N96FEgZiiMx6We23k
9p0SmLvWOET4GPlRScasVYPfZLnghJ8Z0U5uPMv9mtv0BtRF94a9/K8c/MACkDnYSzHV
mAa9cv/FQ+aWPmnnHjuQOT0AQETIObDhORlBCdUt+JqAnuf/OD7ECZdvwJDRDW648+cZ
b9n8q5+H9uh07Bmm1xAXjOaRxMLX9wqQ1WGbKLncgo0FVVApHQYcTc2MrNLT6tAXAEg3 hbNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to; bh=pXpviDmgvdtqsVE7v+Fqpfkk9Ex3XO8+6Q7HsgGu+j0=;
b=RwGinnbpuHcyH/+Soazp2TIgoY9zYPfwXTGg8w5SDLDyUJ9gEjc+0dVZWAeSNW9A42
hNgYS8NAVSK7iz1eXn3Z7gIomHInbIPVBU0lAnu9OtSvdKW1C8c944lej2pz1lhaMprL
pVPIB0oqvIzGPbo+SWFa0MQlN7izj9NxWDT7NfGujvXdEnDV3Wqq8rDxew18y7LtMe1f
Ilmdb/+55aQHV6T/3rka+FwvXOwotLjAua6l7QtG7jEKk7fokn6lPA0f728kfFUZhgqA
D76SFlfFS20ZcUsTtNbcGffHPd14sNDRSF2hjCALBLRHqYMYCLfuVAZMw/0TQso1azbY CgMw==
X-Gm-Message-State:
AGi0Pua2suT/8FskJIKbCZemCz+D6gqVK0Dnccpv2M2BNh8XlZgtZuJG
khMRCItHBUt0O5jpqcY5PBJ46pYaxwbxMXNmElua+A==
X-Google-Smtp-Source:
APiQypK7AygxBafixuAxVpOQpCbJbKYK2WoTK8hkjYA8Mgd7h7XYA8jCl81UFhwlSsEMK4Yp44m6LLhjvmZRorkcZ3U=
X-Received: by 2002:a9d:544:: with SMTP id
62mr21037441otw.165.1588047425133; Mon, 27 Apr 2020 21:17:05 -0700 (PDT)
MIME-Version: 1.0
References: <1594F7B1-B606-4578-8067-72A662D15C44 at gmail.com>
<f4df154ddb868367f5024fd3c2a70af8 at whidbey.com>
<5A6E7D79-E3B4-453C-8590-8479126475A1 at gmail.com>
<CAD8yvAx07GS1c1Tspn9RnGq7=i04wd13nO3w4v44t4Cod3nKJw at mail.gmail.com>
<CAL5GDypu3t92267NCPd7S6g6g55kBm5uAeEH89OFjpcazBChjg at mail.gmail.com>
<5EA74C45.4060402 at jvuletich.org>
In-Reply-To: <5EA74C45.4060402 at jvuletich.org>
From: Luciano Notarfrancesco <luchiano at gmail.com>
Date: Tue, 28 Apr 2020 11:16:54 +0700
Message-ID:
<CAL5GDyr67soMWSuwNRt9uBG2Hoh_ft4wRu-Rkzx8LJv0RutivQ at mail.gmail.com>
Subject: Re: [Cuis-dev] Naming conventions
To: Juan Vuletich <juan at jvuletich.org>
Content-Type: multipart/alternative;
boundary="000000000000a9619705a4521a5a"
X-Spam-Status: No, score=-0.8
X-Spam-Score: -7
X-Spam-Bar: /
X-Spam-Flag: NO
Sounds great! But the convention
`PackageName1@#ClassName` new
looks a bit ugly to me, how about using upper case messages via the DNU
mechanism? Say, a package PackageName1 is already a global in the
Smalltalk system dictionary, then you can do send ClassName as a message
to it:
PackageName1 ClassName new
And regarding the back ticks, normally the compiled methods would have a
reference to the association, but if you resolve it to a class at
compile time and a class is replaced by a new one in the package, the
compiled method outside would keep the reference to the old class.
On Tue, 28 Apr 2020 at 4:19 AM, Juan Vuletich <juan at jvuletich.org
<mailto:juan at jvuletich.org>> wrote:
Hi Folks,
On 4/27/2020 12:52 PM, Luciano Notarfrancesco via Cuis-dev wrote:
> I also dislike prefixes a lot. But fortunately name clashes are
> less common in Cuis because there are not as many classes as in
> Pharo. Personally, I’d love to have namespaces, or have class
> names be local to a package.
Ok, this got me thinking. So, what would it take to do just that?
We could make each package be a namespace. That means that classes
that are defined in a package will not be globals. But, any package
declaring a prerequisite would also behave as if in Python you did
'From package import *'. So, the compiler would know that it is
compiling some code for some package, and it would try to find class
names in all packages that were declared as prerequisites.
This would have the added benefit that the compiler would check for
you that you actually declared prerequisites. Code not in a package
would not have access to classes defined at any package.
Usually, there would be no need to specify namespaces when accessing
'globals', even if they belong in a different package/namespace.
Just declaring the prerequisites for your package just once, will
do. The only case where explicit call for a namespace would be
needed, is if you ask two prerequisites, they both define classes
with the same name, and there is ambiguity. In such casses something
like:
a := `Smalltalk@#PackageName1@#ClassName` new.
b := `Smalltalk@#PackageName2@#ClassName` new.
would work as expected. See that class resolution is done at compile
time because of the use of backticks. So there's no performance
penalty. Also, there's no new syntax!
If we add package names to the Smalltlak global namespace, then we
could also do:
a := `PackageName1@#ClassName` new.
b := `PackageName2@#ClassName` new.
Again, this is only when the case is that you decided to depend on
two different packages that happen to clash. So, you are already
aware of the situation. This would never get in your way when good
old Smalltalk would do!
There's some work to be done in Browsers and other tools, but I feel
it is not too much...
Also note that I'd not include nested namespaces, just like we don't
have nested packages. I'd also avoid having namespaces as a separate
thing from packages. I'd have a single concept for both. So, it
would be simpler than what is available in other Smalltalks that
support namespaces.
Does this make sense? I am missing something?
Thanks,
--
Juan Vuletich
www.cuis-smalltalk.org <http://www.cuis-smalltalk.org>
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich
>
> On Mon, 27 Apr 2020 at 10:46 PM, giorgio ferraris via Cuis-dev
> <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
>
> Hello,
> prefixes have a long story, in use also on VisualSmalltalk or
> SmalltalkV long, long time ago. Not having namespaces on many
> Smalltalk dialects makes prefix the only (ugly) solution.
> The resulting names are horrible, I personally dislike it a
> lot, but class' names clashing is something that could easily
> happens.
>
> ciao
>
> giorgio
>
>
>
> On Mon, Apr 27, 2020 at 5:34 PM Erik Stel via Cuis-dev
> <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
>
> Hi Ken,
>
> I think you just answered my question ;-).
>
> It can indeed be a Pharo ’thing’. In Pharo (default image)
> you have class names like ’ZnWebSocket’. It represents a
> WebSocket and comes from the ‘Zinc’ framework. I think it
> coexisted with WebSocket for some time (the later is no
> longer part of the default Pharo image). Also ‘MCPackage’
> is a package from Monticello (the versioning system). A
> full name like ‘MonticelloPackage’ would have solved that
> issue of name conflict I suppose.
>
> Regards,
> Erik
>
>
> > On 27 Apr 2020, at 17:13, ken.dickey at whidbey.com
> <mailto:ken.dickey at whidbey.com> wrote:
> >
> > On 2020-04-27 07:28, Erik Stel via Cuis-dev wrote:
> >> Hi,
> >> Short question:
> >> Also using Pharo, I’m used to creating classes with
> prefixed names
> >> because of possible name collisions. What is the Cuis
> take on these
> >> prefixes? I do not see any prefixes being used in the
> >> packages/features I’m using at the moment.
> >> Regards,
> >> Erik
> >
> > Examples?
> >
> > What is the context?
> >
> > Not being a Pharo user, I have no idea what you are
> talking about.
> >
> > Typically, one wants to use meaningful names in a way
> that orients one and makes code reads like sentences.
> >
> > Note that the base Cuis image typically has between 500
> and 600 classes. The latest Pharo base image has over
> 9000 classes. Perhaps the (pre)fix is for a Pharo problem..
> >
> > -KenD
> >
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200428/4ee2ff78/attachment-0001.htm>
More information about the Cuis-dev
mailing list