[Cuis-dev] Naming conventions
Juan Vuletich
juan at jvuletich.org
Thu Apr 30 11:55:52 PDT 2020
On 4/29/2020 12:57 AM, Luciano Notarfrancesco via Cuis-dev wrote:
>
>
> On Tue, 28 Apr 2020 at 8:52 PM, Juan Vuletich <juan at jvuletich.org
> <mailto:juan at jvuletich.org>> wrote:
>
>
> Without backticks, we'd need to add packages as globals, so they
> can be
> resolved at runtime. With the backticks we can avoid that, because we
> can give the Compiler the context to resolve package names if in a
> required package, just like class names, at compile time.
>
>
> But that would work regardless of back ticks, right? Erik doesn’t like
> backticks very much, I also avoid them in my code.
>
> I just did some experiments changing Class>>bindingOf:. Currently it
> first looks in class var names and SharedPools calling
> localBindingOf:, then it looks in globals by calling Smalltalk
> bindingOf:. I added a packageBindingOf: after localBindingOf:, and if
> self package is not nil it tries to resolve the binding within the
> package. We can put required packages here and they will look like
> globals, right? And also resolve classes of the local package.
You are right! Yes, the backticks are optional. There is still the
message send to get the class. So there is some performance penalty, and
some users in critical code might still prefer to use them, so the
literal is the class and not the module. But it is a small detail.
> I tried one of the ideas: keeping all classes global, but adding a
> prefix like ‘PackageName.’ to the binding key in the Smalltalk system
> dictionary. I added a Class>>globalName too. Seems to almost work, but
> tools break all over the place.
>
>
Cheers,
--
Juan Vuletich
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200430/458ee75e/attachment.htm>
More information about the Cuis-dev
mailing list