[Cuis-dev] Language constructs

Fri May 1 00:45:51 PDT 2020

Maybe I wasn’t clear (because it was part of another topic, see below) or tread on a sensitive subject, but I’m still eager to hear the reasoning for having backticks (which are not in Squeak nor Pharo) from the simplicity point of view. Would anyone care to elaborate?

I am also eager to know what others think about language constructs such as #(), {} and `` for daily usage. And I mean this in the sense ‘Do you use these often? Could you live without them?’. I do understand how they can be used and what their meaning is ;-). And I can also lookup their current use in the default image, but that does not answer how you/we use them in our (application) code.

Kind regards,
Erik

> Hi Juan, others,
> 
> Chewing on this a bit today, I have to admit I am not a big fan of the backticks nor adding extra globals. So although I started with a question that led to this thread I vote for keeping it as it is: without namespaces. :-)
> 
> In my opinion, the backticks add additional complexity which is not needed. Literals for Numbers, Characters and Strings is a necessity (how would you otherwise create instances for these classes). Writing literals for Points, Arrays, etc is perfectly doable with regular Smalltalk expressions. And having to remember that a literal is created at compile time instead of runtime is not something that feels really dynamic as in ’the Smalltalk way’. What would happen if I change the implementation of Point>>#@? Will all code be recompiled which uses the literal `0 @ 0`? If we expect backticks to create literals at compile time, I’m not even sure I know what the (correct) answer should be. The performance gain is not something I’m interested in. We can create (lazy initialised or not) variables to hold instances which require more elaborate instantiation logic or for often used ‘values’ like [Point zero] (example, this does not exist).
> 
> Only recently have I began to use [{ #first . #second . #third }], to be compatible with other code. And sure it is much more compact than [(Array new: 3) at: 1 put: #first ; at: 2 put: #second ; at: 3 put: #third ; yourself], but the later is very clear in what it does. I hardly ever use [#(first second third)] because it is (in my opinion) at first sight unclear what first, second and third are. You could use [#(first #second third)] or [#(#first #second #third)] which all have the same effect, but look different. Confusing I think (and I say this as a long time developer). I’m working on a project to create a development environment for kids (based on Smalltalk and preferably Cuis), I’m not sure I want to have to explain these things.
> 
> I like Cuis’ simplicity, but I am unsure whether backticks (nor the other literal constructions {} and #()) are helping here. If any I would keep {} and remove the rest. So to come back to my earlier remark: I think I prefer Cuis without namespaces to not add complexity. And not prefixing class names fits fine in the simplicity corner.
> 
> Eager to hear other opinions and hear the reasoning which led to the current literal constructions.
> 
> My 2 eurocents.
> 
> Kind regards,
> Erik
> 
> 
>> On 28 Apr 2020, at 16:00, cuis-dev-request at lists.cuis.st <mailto:cuis-dev-request at lists.cuis.st> wrote:
>> 
>> From: Juan Vuletich <juan at jvuletich.org <mailto:juan at jvuletich.org>>
>> Subject: Re: [Cuis-dev] Naming conventions
>> Date: 28 April 2020 at 15:52:08 CEST
>> To: Luciano Notarfrancesco <luchiano at gmail.com <mailto:luchiano at gmail.com>>, Discussion of Cuis Smalltalk <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>>
>> 
>> 
>> On 4/28/2020 1:16 AM, Luciano Notarfrancesco wrote:
>>> 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
>> 
>> Yes, this is cleaner.
>> 
>>> 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.
>> 
>> 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.
>> 
>> Additionally, using DNU instead of #@ has a significant performance penalty. I would only use DNU if in backticks, so there is no additional cost in every method run.
>> 
>> WRT the class being recreated, yes, we need track and recompile references. Not a big deal.
>> 
>> So, I think there are three alternatives:
>> 
>> a)  `PackageName1@#ClassName` new         #@ message send, package name is required, no global needed. Evaluated at compile time.
>> b)  (PackageName1@#ClassName) new         #@ message send. Package name is a global. Evaluated at method run time.
>> c)   `PackageName1 ClassName` new             DNU mechanism. Backticks used for performance. No global needed.
>> 
>> I think I prefer option c). It looks clean, has no performance penalty, and doesn't need additional globals.
>> 
>> Thanks,
>> 
>> -- 
>> Juan Vuletich
>> www.cuis-smalltalk.org <http://www.cuis-smalltalk.org/>
>> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev <https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev>
>> https://github.com/jvuletich <https://github.com/jvuletich>
>> https://www.linkedin.com/in/juan-vuletich-75611b3 <https://www.linkedin.com/in/juan-vuletich-75611b3>
>> @JuanVuletich
>> 
> 
> 
> 
> Cuis-dev mailing list
> 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/20200501/2dcf19ed/attachment-0001.htm>