Hi Dmitry, you found it yourself, sort of! Le 31/10/2016 à 14:25, CodeDmitry a écrit :

Wait, so unlike JavaScript; True and False are actual singletons and ifTrue/ifFalse/ifTrue:ifFalse: uses visitor pattern to have the actual True or False handle the block rather than doing it themselves?

Yes, true and false are singletons (resp single instance of the True class, False class). No, this is not a visitor pattern, just polymorphism (True and False have their own implementation of ifTrue:/ifFalse:/ifTrue:ifFalse:/ifFalse:ifTrue:). Regards, Thierry

Le 31/10/2016 à 14:58, CodeDmitry a écrit :

But still, how is the actual argument "alternativeBlock" passed to the True/False from a Boolean?

The message does not cache the message inside itself before passing the message, and it does not pass the alternative block along with the message.

If I get correctly what you are saying, this is because the ifTrue:ifFalse: message is never sent to an instance of Boolean. It is sent either to true, the single instance of class True, or to false, the single instance of class False, where the implementation is what you expect: False>>#ifTrue:ifFalse: ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock "Answer the value of falseAlternativeBlock. Execution does not actually reach here because the expression is compiled in-line." ^falseAlternativeBlock value If you're interested in the details, do also read the comment. Regards, Thierry

For the full story, these objects and ifTrue: etc are special cases in the VM code. For speed. Phil On Mon, Oct 31, 2016 at 3:32 PM, CodeDmitry <dimamakhnin@gmail.com> wrote:

I realized it a bit before you posted but thanks for confirming.

Boolean seems to indeed just be a "Dynamic Interface"; since Smalltalk does not have "Java Interfaces"(nor want them for the same reason JavaScript doesn't), the developers wanted to still have True and False be subclasses of Booleans.

In all honesty Boolean seems to be there purely for the "common sense" of it, rather than need. Smalltalk is duck typed and has no need for interfaces. If it's a Boolean, you know it has those methods so Boolean is not actually useful for anything; True and False may as well just be subclasses of Object.

-- View this message in context: http://forum.world.st/How- does-Boolean-ifTrue-work-tp4920873p4920891.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Ah so it's more of a "dynamic abstract class" than a "dynamic interface", so they do get visited during the traversal of the inheritence chain(rather than skipped immediately to Object). -- View this message in context: http://forum.world.st/How-does-Boolean-ifTrue-work-tp4920873p4920896.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

I meant "dynamic" as a contrast to Java's abstract classes/interfaces which are going to slap you if you forget to implement one of the abstract methods, so the only reason to define the methods that are going to be overwritten seems to be to disambiguate the error message that will be raised from the selector not being there. -- View this message in context: http://forum.world.st/How-does-Boolean-ifTrue-work-tp4920873p4920905.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

CodeDmitry wrote

Why don't Smalltalk or Smalltalklike languages have checked interfaces? The compilation occurs at runtime but it is still technically a compilation, why don't languages allow implementing interfaces at runtime? The type information is there, and the source can load the list of messages expected and check if the compiled class contains all members or removes it and throws an exception. Is this just too expensive?

Because you never do a batched class def + all methods compilation, which would be the proper place to raise an exception that you're missing something, in a normal Smalltalk workflow. First you compile a class definition, then you add/compile methods defining instance behaviour of that class. Instead, a good code critic will inform you if there are subclassResponsibilities remaining to be defined. If you disregard that, and actually try to use the method on an instance, you get the runtime exception instead. Also, traits can work as a sort-of-interface with behaviour defined ala abstract classes like Boolean, with the benefit that they are not restricted by class hierarchy, and the downside that the behaviour they define, can't access any state directly. Interfaces in other languages often feel somewhat self-defeating in my mind other than as a way to satisfy the typing system; the API you want polymorphic across implementors is usually a high-level one (akin to the protocol in Boolean sans subclassResponsibilities), while the state that actually needs to be different, is (usually) rather low-level. So if you use an API interface across class hierarchies, copy pasta is inevitable, while if you stay within a single hierarchy, what do you need the interface for anyways? If you instead define/share the low level interface that actually needs to differ, the temptation of adding Helper Classes containing the actual behaviour, and all of a sudden, you've split state and behaviour. At which point you've avoided duplication of code, but you can't really call it OO any more either. Cheers, Henry -- View this message in context: http://forum.world.st/How-does-Boolean-ifTrue-work-tp4920873p4921198.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

On 2 November 2016 at 20:36, Henrik Sperre Johansen < henrik.s.johansen@veloxit.no> wrote:

CodeDmitry wrote

...

Why don't Smalltalk or Smalltalklike languages have checked interfaces? The compilation occurs at runtime but it is still technically a compilation, why don't languages allow implementing interfaces at runtime? The type information is there, and the source can load the list of messages expected and check if the compiled class contains all members or removes it and throws an exception. Is this just too expensive?

<rude mode on> because it's smalltalk. and because you don't come into existing temple with own rules </rude mode still on> well.. i hope you will stay here a little bit longer, to learn and undestand, that what you proposing/asking for is ether already there in one or another form, or simply unnecessary. P.S. please forgive me for being rude, impatient and trollish towards newcomers.. but i just can't help with it. -- Best regards, Igor Stasenko.

Actually sorry Igor but you are wrong, you just defeated the purpose of Smalltalk. To expose you to the internals. Of course you can implement interfaces. You can even implement static types. You can do anything you want. The compiler is written in Smalltalk after all. On Wed, 2 Nov 2016 at 23:02, Igor Stasenko <siguctua@gmail.com> wrote: If you want to ensure that your class(es) comply with certain protocol, just write a test that covers the protocol and checks that class instances will understand messages you want it to understand. But there's no way to restrict your class to comply to whole protocol once at a time, because tools made in a way, that you populating your class with methods, each method is add individually and compiled separately, and the only validation, the compiler is capable of is basically compliance with smalltalk syntax. And it doesn't cares about higher lever requirement, like whether your class turns to be 'valid' because of a method you just added, ready to be used and for what. Even more, there's no way to connect all those 'interface' formalisation garbage rules with send sites (the place where you actually invoking one or another method of one of potetial implementor of your interface), so it makes no sense to do any (pre)validation on whatever class/object in a system in order to check whether it conforms with it or not. That's " Why don't Smalltalk or Smalltalklike languages have checked interfaces?" -- Best regards, Igor Stasenko.

I don't agree with you not agreeing with me, because I never said it would be Smalltalk or Pharo (for those that think that Pharo is not Smalltalk). Yes Strongtalk is a good example, in the case of Pharo you could retain compatibility with Pharo if you followed the example of Hy lang http://docs.hylang.org/en/latest/ Basically Hy is a lisp dialect that runs on top of python , using python's AST library, from one hand it gives you lisp including macros on the other it outputs pure python code which means you can use any python library from Hy and any Hy library from python without any wrapping or extra steps. If you can do this in Python imagine the potential of Pharo. I am itching actually to implement my own lisp dialect in Pharo. On Thu, Nov 3, 2016 at 3:06 PM Johan Fabry <jfabry@dcc.uchile.cl> wrote:

I don’t agree with that, if you implement static types or interfaces it’s no longer really Smalltalk. It would be (a variant of) Strongtalk http://www.bracha.org/nwst.html http://www.strongtalk.org/index.html

-- Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org .

Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

On 03 Nov 2016, at 03:11, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

Actually sorry Igor but you are wrong, you just defeated the purpose of Smalltalk. To expose you to the internals. Of course you can implement interfaces. You can even implement static types. You can do anything you want.

The compiler is written in Smalltalk after all.

On Wed, 2 Nov 2016 at 23:02, Igor Stasenko <siguctua@gmail.com> wrote:

If you want to ensure that your class(es) comply with certain protocol, just write a test that covers the protocol and checks that class instances will understand messages you want it to understand. But there's no way to restrict your class to comply to whole protocol once at a time, because tools made in a way, that you populating your class with methods, each method is add individually and compiled separately, and the only validation, the compiler is capable of is basically compliance with smalltalk syntax. And it doesn't cares about higher lever requirement, like whether your class turns to be 'valid' because of a method you just added, ready to be used and for what. Even more, there's no way to connect all those 'interface' formalisation garbage rules with send sites (the place where you actually invoking one or another method of one of potetial implementor of your interface), so it makes no sense to do any (pre)validation on whatever class/object in a system in order to check whether it conforms with it or not. That's " Why don't Smalltalk or Smalltalklike languages have checked interfaces?"

-- Best regards, Igor Stasenko.

OK but the original question was "Why don't Smalltalk or Smalltalklike

languages have checked interfaces?” and my mail was an answer to that.

You are correct, I did not read carefully and made the mistake to assume that it was about not being possible. " I think there was Lisp for Squeak (and also Prolog). And port to Pharo should not be difficult. " Ah yes thanks for reminding , my intention was to do it from scratch mainly as an opportunity to understand the basics of parsers, AST and compilers etc but still could really help to see those examples. These are the links I am using for assistance https://gist.github.com/kilon/486629e5858e23c87dd8ede236dc8bfa

On 3 November 2016 at 07:11, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

Actually sorry Igor but you are wrong, you just defeated the purpose of Smalltalk. To expose you to the internals. Of course you can implement interfaces. You can even implement static types. You can do anything you want.

So, why you asking then 'why smalltalk doesn't have .... ' when you know that in smalltalk you can do anything you want? Yes, you can do anything you want, but not everything you can do makes sense to do. And it doesn't defeats the purpose of smalltalk, it just defeats the common sense. And last one, i don't understand what kind of 'exposure to internals' you are talking about. In smalltalk people used to write a functional tests, to check that your code behaves as intended. Now you proposing to introduce static interfaces, borrowed from other lanuages, the only purpose of which is to declare that your code *could* behave as intended, no guarantees , nothing. Just a set of formal rules on top of existing ones, with ZERO end effect and benefits. You want it? You are free to implement it. Good look with it.. I wonder, why so many people think that if they put soft pillows everywhere, seal the doors (because outside is dangerous) , and after sealing and pillowing everything they happily rest with thought 'now we are safe'.. not realizing, that they built a perfect jail for themselves, without any means to escape from it and do something in real world. The compiler is written in Smalltalk after all.

On Wed, 2 Nov 2016 at 23:02, Igor Stasenko <siguctua@gmail.com> wrote:

If you want to ensure that your class(es) comply with certain protocol, just write a test that covers the protocol and checks that class instances will understand messages you want it to understand. But there's no way to restrict your class to comply to whole protocol once at a time, because tools made in a way, that you populating your class with methods, each method is add individually and compiled separately, and the only validation, the compiler is capable of is basically compliance with smalltalk syntax. And it doesn't cares about higher lever requirement, like whether your class turns to be 'valid' because of a method you just added, ready to be used and for what. Even more, there's no way to connect all those 'interface' formalisation garbage rules with send sites (the place where you actually invoking one or another method of one of potetial implementor of your interface), so it makes no sense to do any (pre)validation on whatever class/object in a system in order to check whether it conforms with it or not. That's " Why don't Smalltalk or Smalltalklike languages have checked interfaces?"

-- Best regards, Igor Stasenko.

-- Best regards, Igor Stasenko.

On 3 November 2016 at 22:36, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

Igor you confuse me with someone else I never asked why Smalltalk doesn't have... nor I said that I want static types and interfaces. I am actually trying to use a Pharo instead of C++ with Unreal.

I hate static types and I hate interfaces. Only pointed that is possible. I don't like languages that think they are smarter than me. I love my freedom thank you very much and I love Pharo as it is language wise.

sorry, i confused you with the original question of CodeDmitry.

On Thu, 3 Nov 2016 at 23:16, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 3 November 2016 at 07:11, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

Actually sorry Igor but you are wrong, you just defeated the purpose of Smalltalk. To expose you to the internals. Of course you can implement interfaces. You can even implement static types. You can do anything you want.

So, why you asking then 'why smalltalk doesn't have .... ' when you know that in smalltalk you can do anything you want? Yes, you can do anything you want, but not everything you can do makes sense to do. And it doesn't defeats the purpose of smalltalk, it just defeats the common sense.

And last one, i don't understand what kind of 'exposure to internals' you are talking about. In smalltalk people used to write a functional tests, to check that your code behaves as intended. Now you proposing to introduce static interfaces, borrowed from other lanuages, the only purpose of which is to declare that your code *could* behave as intended, no guarantees , nothing. Just a set of formal rules on top of existing ones, with ZERO end effect and benefits. You want it? You are free to implement it. Good look with it..

I wonder, why so many people think that if they put soft pillows everywhere, seal the doors (because outside is dangerous) , and after sealing and pillowing everything they happily rest with thought 'now we are safe'.. not realizing, that they built a perfect jail for themselves, without any means to escape from it and do something in real world.

The compiler is written in Smalltalk after all.

On Wed, 2 Nov 2016 at 23:02, Igor Stasenko <siguctua@gmail.com> wrote:

If you want to ensure that your class(es) comply with certain protocol, just write a test that covers the protocol and checks that class instances will understand messages you want it to understand. But there's no way to restrict your class to comply to whole protocol once at a time, because tools made in a way, that you populating your class with methods, each method is add individually and compiled separately, and the only validation, the compiler is capable of is basically compliance with smalltalk syntax. And it doesn't cares about higher lever requirement, like whether your class turns to be 'valid' because of a method you just added, ready to be used and for what. Even more, there's no way to connect all those 'interface' formalisation garbage rules with send sites (the place where you actually invoking one or another method of one of potetial implementor of your interface), so it makes no sense to do any (pre)validation on whatever class/object in a system in order to check whether it conforms with it or not. That's " Why don't Smalltalk or Smalltalklike languages have checked interfaces?"

-- Best regards, Igor Stasenko.

-- Best regards, Igor Stasenko.

-- Best regards, Igor Stasenko.

"not realizing, that they built a perfect jail for themselves, without any means to escape from it and do something in real world." Right on Igor. I hate jails. Pharo is such a breath of fresh air. I can kill myself in all kinds of ways, each of which led a step further on the path towards enlightment in coderland. Pharo|Smalltalk: also acts as a pretty good coder filter. Phil On Thu, Nov 3, 2016 at 10:15 PM, Igor Stasenko <siguctua@gmail.com> wrote:

On 3 November 2016 at 07:11, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

...

Actually sorry Igor but you are wrong, you just defeated the purpose of Smalltalk. To expose you to the internals. Of course you can implement interfaces. You can even implement static types. You can do anything you want.

So, why you asking then 'why smalltalk doesn't have .... ' when you know that in smalltalk you can do anything you want? Yes, you can do anything you want, but not everything you can do makes sense to do. And it doesn't defeats the purpose of smalltalk, it just defeats the common sense.

And last one, i don't understand what kind of 'exposure to internals' you are talking about. In smalltalk people used to write a functional tests, to check that your code behaves as intended. Now you proposing to introduce static interfaces, borrowed from other lanuages, the only purpose of which is to declare that your code *could* behave as intended, no guarantees , nothing. Just a set of formal rules on top of existing ones, with ZERO end effect and benefits. You want it? You are free to implement it. Good look with it..

I wonder, why so many people think that if they put soft pillows everywhere, seal the doors (because outside is dangerous) , and after sealing and pillowing everything they happily rest with thought 'now we are safe'.. not realizing, that they built a perfect jail for themselves, without any means to escape from it and do something in real world.

The compiler is written in Smalltalk after all.

...

On Wed, 2 Nov 2016 at 23:02, Igor Stasenko <siguctua@gmail.com> wrote:

If you want to ensure that your class(es) comply with certain protocol, just write a test that covers the protocol and checks that class instances will understand messages you want it to understand. But there's no way to restrict your class to comply to whole protocol once at a time, because tools made in a way, that you populating your class with methods, each method is add individually and compiled separately, and the only validation, the compiler is capable of is basically compliance with smalltalk syntax. And it doesn't cares about higher lever requirement, like whether your class turns to be 'valid' because of a method you just added, ready to be used and for what. Even more, there's no way to connect all those 'interface' formalisation garbage rules with send sites (the place where you actually invoking one or another method of one of potetial implementor of your interface), so it makes no sense to do any (pre)validation on whatever class/object in a system in order to check whether it conforms with it or not. That's " Why don't Smalltalk or Smalltalklike languages have checked interfaces?"

-- Best regards, Igor Stasenko.

-- Best regards, Igor Stasenko.

more than that. You can define code in Boolean in terms of the abstract methods and such code will be executed on instance of True and False using False and True methods. You are learning now for real what is OOP. So your teacher is a really smart teacher because he chose to expose you to objects and OOP thinking for real. Stef Le 31/10/16 à 15:58, CodeDmitry a écrit :

Ah so it's more of a "dynamic abstract class" than a "dynamic interface", so they do get visited during the traversal of the inheritence chain(rather than skipped immediately to Object).

-- View this message in context: http://forum.world.st/How-does-Boolean-ifTrue-work-tp4920873p4920896.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Hi Dmitry, You've just bumped into one of Smalltalk's paradigms that may change the way you *think* about programming ;). For me it was certainly an eye-opener. It intrigued me there could even exist another way to *think* about booleans. On Mon, Oct 31, 2016 at 10:06 PM, jtuchel@objektfabrik.de <jtuchel@objektfabrik.de> wrote:

When I teach Smalltalk, this is one of the most beautiful exercises for students. Those who get it will love Smalltalk, those who don't often leave the project soon ;-)

Interesting insight. On Mon, Oct 31, 2016 at 10:32 PM, CodeDmitry <dimamakhnin@gmail.com> wrote:

Boolean seems to indeed just be a "Dynamic Interface"; since Smalltalk does not have "Java Interfaces"(nor want them for the same reason JavaScript doesn't), the developers wanted to still have True and False be subclasses of Booleans.

In all honesty Boolean seems to be there purely for the "common sense" of it, rather than need. Smalltalk is duck typed and has no need for interfaces. If it's a Boolean, you know it has those methods so Boolean is not actually useful for anything; True and False may as well just be subclasses of Object.

Not quite. Yes most of Boolean's own methods are mostly subclassResponsibilitys, but you can see Boolean provides a place for extensions by *Fuel, *Reflectivity, *ston-core and *UnifiedFFI packages to hang methods common to both True and False. The best way to properly understand this is to observe it in action yourself, by debugging through it. Except you can't debug it since #ifTrue:#iFalse is inlined for performance. Instead try defining... True>>myifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock ^trueAlternativeBlock value False>>myifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock ^falseAlternativeBlock value then from Playground, debug... true myifTrue: [self inform: 'true'] ifFalse: [self inform: 'false']. false myifTrue: [self inform: 'true'] ifFalse: [self inform: 'false']. and just continue stepping <Into>, (except step <Over> the #inform: when you get there) cheers -ben

myCollection isEmpty ifTrue: [ self inform: 'The collection is empty' ]. First #isEmpty is sent to myCollection which results in either true or false as value. Then #ifTrue: is sent to this value. Now, if the value was true (the sole instance of class True), the code in True>>#ifTrue: is executed, which will evaluate the block by sending it #value. If the value was false, the code in False>>#ifTrue: is executed, and nil is returned and the block is not executed. Like others said, it is just polymorphism at work. (And yes, the compiler optimises some of this logic a bit, but the effect is the same).

On 31 Oct 2016, at 14:58, CodeDmitry <dimamakhnin@gmail.com> wrote:

But still, how is the actual argument "alternativeBlock" passed to the True/False from a Boolean?

The message does not cache the message inside itself before passing the message, and it does not pass the alternative block along with the message.

-- View this message in context: http://forum.world.st/How-does-Boolean-ifTrue-work-tp4920873p4920886.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Am 31.10.2016 um 15:59 schrieb phil@highoctane.be:

but you should use myCollection ifEmpty: [ ... ]

Why? Norbert

Phil

On Mon, Oct 31, 2016 at 3:25 PM, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote: myCollection isEmpty ifTrue: [ self inform: 'The collection is empty' ].

First #isEmpty is sent to myCollection which results in either true or false as value.

Then #ifTrue: is sent to this value.

Now, if the value was true (the sole instance of class True), the code in True>>#ifTrue: is executed, which will evaluate the block by sending it #value. If the value was false, the code in False>>#ifTrue: is executed, and nil is returned and the block is not executed.

Like others said, it is just polymorphism at work.

(And yes, the compiler optimises some of this logic a bit, but the effect is the same).

...

On 31 Oct 2016, at 14:58, CodeDmitry <dimamakhnin@gmail.com <mailto:dimamakhnin@gmail.com>> wrote:

But still, how is the actual argument "alternativeBlock" passed to the True/False from a Boolean?

The message does not cache the message inside itself before passing the message, and it does not pass the alternative block along with the message.

-- View this message in context: http://forum.world.st/How-does-Boolean-ifTrue-work-tp4920873p4920886.html <http://forum.world.st/How-does-Boolean-ifTrue-work-tp4920873p4920886.html> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

2016-10-31 16:11 GMT+01:00 Norbert Hartl <norbert@hartl.name>:

Am 31.10.2016 um 15:59 schrieb phil@highoctane.be:

but you should use myCollection ifEmpty: [ ... ]

Why?

because it shorter :)

Am 31.10.16 um 15:59 schrieb phil@highoctane.be:

but you should use myCollection ifEmpty: [ ... ]

interesting. Why do you think so? what if you wanted your code to be portable across Smalltalk dialects?

-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Phil, I see your point but disagree. I don't use Pharo regularly, so I cannot currently check if the implementation around this emptiness check is complete. With complete I mean that following your logic, theere should be at least implementations of ifEmpty: ifNotEmpty: ifEmpty:ifNotEmpty: ifEmptyOrNil: ifEmptyOrNil:otherwise: I really have to check for the size of collections very often, and the size of 1 is a very frequent case. So why not add: ifExactlyOne: ifSizeIs:do: ifSizeIsGreaterThan:do:otherwiseDo: You get the picture. I strongly believe this leads to pollution and ends up in a mess. We could save so much typing and make our programs so much more readable if we only were a bit more creative, right? ;-) A DSL is another story, though. If you write a Library that makes handling Collections nicer, this is okay and the methods are good to exist in its context. But they shouldn't necessarily all be part of the base image. Don't get me wrong: if you and the Pharo community agree on lots of convenience methods, that is okay for me, and I find myself adding such methods to VA Smalltalk from time to time. I appreciate many of them being brought to VA ST in Grease. Sometimes, this is simply a question of taste, sometimes it saves typing, sometimes it helps to improve readability of code. But I wouldn't go so far to tell people they should better use such a method as a general advice. I would probably tell them: "look, here's a method I find much more elegant, you could *also* use that to save typing/increase readability". Just my 2 cents, and highly off topic ;-) Joachim Am 01.11.16 um 08:43 schrieb phil@highoctane.be:

Because I grew tired of the isEmpty ifTrue: [ ] all over the place. And ifEmpty has the right semantics for my use cases (like assignment).

I do not really care about portability, I am doing Pharo only.

Phil

On Mon, Oct 31, 2016 at 5:30 PM, jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> <jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de>> wrote:

Am 31.10.16 um 15:59 schrieb phil@highoctane.be <mailto:phil@highoctane.be>:

...

but you should use myCollection ifEmpty: [ ... ]

interesting. Why do you think so? what if you wanted your code to be portable across Smalltalk dialects?

...

-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchelmailto:jtuchel@objektfabrik.de Fliederweg 1http://www.objektfabrik.de D-71640 Ludwigsburghttp://joachimtuchel.wordpress.com <http://joachimtuchel.wordpress.com> Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Am 01.11.16 um 11:36 schrieb Denis Kudriashov:

2016-11-01 11:31 GMT+01:00 jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> <jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de>>:

ifEmpty: ifNotEmpty: ifEmpty:ifNotEmpty:

It is already in image and feels exactly like ifNil:/ifNotNil. For other cases I think it is too much.

are they also implemented in UndefinedObject?

Am 01.11.2016 um 12:21 schrieb Esteban Lorenzano:

...

On 1 Nov 2016, at 11:39, jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> wrote:

are they also implemented in UndefinedObject?

no, because empty != nil

I know. That's exactly the reason why I never use isEmptyOrNil 😉 Fun aside: how often do we need to check if some code returns nil or an empty collection. My question was aimed at exactly this: in practice ifEmptyOrNil: would probably be even more frequently needed than ifEmpty:. Otherwise, the beautiful convenience method has to be guarded by a nil test.... so we end up writing lots of methods, and not all of them seem to be universal enough to be part of the base image, imo. Joachim

Esteban

On 1 November 2016 at 11:31, jtuchel@objektfabrik.de < jtuchel@objektfabrik.de> wrote:

Phil,

I see your point but disagree. I don't use Pharo regularly, so I cannot currently check if the implementation around this emptiness check is complete.

With complete I mean that following your logic, theere should be at least implementations of

ifEmpty: ifNotEmpty: ifEmpty:ifNotEmpty: ifEmptyOrNil: ifEmptyOrNil:otherwise:

why pollution? it just convenience method. mind you, that #isEmpty is also convenience method, without it you would do it like: myArray size isZero ifTrue: [] of wait.. #isZero also convenience method... so if you elitist then you have to write it like that: myArray size = 0 ifTrue: [] And that , to my opinion, adds even more pollution to the user code, because first, it is longer, and second #ifEmpty: much better clarifies the intent of author, comparing to size = 0

I really have to check for the size of collections very often, and the size of 1 is a very frequent case. So why not add:

ifExactlyOne: ifSizeIs:do: ifSizeIsGreaterThan:do:otherwiseDo:

You get the picture. I strongly believe this leads to pollution and ends up in a mess. We could save so much typing and make our programs so much more readable if we only were a bit more creative, right? ;-) A DSL is another story, though. If you write a Library that makes handling Collections nicer, this is okay and the methods are good to exist in its context. But they shouldn't necessarily all be part of the base image.

Don't get me wrong: if you and the Pharo community agree on lots of convenience methods, that is okay for me, and I find myself adding such methods to VA Smalltalk from time to time. I appreciate many of them being brought to VA ST in Grease.

Sometimes, this is simply a question of taste, sometimes it saves typing, sometimes it helps to improve readability of code.

But I wouldn't go so far to tell people they should better use such a method as a general advice. I would probably tell them: "look, here's a method I find much more elegant, you could *also* use that to save typing/increase readability".

Just my 2 cents, and highly off topic ;-)

Joachim

Am 01.11.16 um 08:43 schrieb phil@highoctane.be:

Because I grew tired of the isEmpty ifTrue: [ ] all over the place. And ifEmpty has the right semantics for my use cases (like assignment).

I do not really care about portability, I am doing Pharo only.

Phil

On Mon, Oct 31, 2016 at 5:30 PM, jtuchel@objektfabrik.de < jtuchel@objektfabrik.de> wrote:

...

Am 31.10.16 um 15:59 schrieb phil@highoctane.be:

but you should use myCollection ifEmpty: [ ... ]

interesting. Why do you think so? what if you wanted your code to be portable across Smalltalk dialects?

...

-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de <jtuchel@objektfabrik.de> Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

--

---

Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de <jtuchel@objektfabrik.de> Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

-- Best regards, Igor Stasenko.

On 1 November 2016 at 17:00, phil@highoctane.be <phil@highoctane.be> wrote:

Hey Igor is around \o/

Hey heya! :)

BTW using size = 0 triggers a code critic telling you to use isEmpty.

Maybe there is a rule of isEmpty ifTrue: :-)

I think that there could be a lot of convenience methods in the base image. They can be in an extension protocol, no issue. STON and gt have a ton of these. In the base image.

About beginners, well: have a look in some Zinc code and learn a truckload of tricks. Like inject: somePath into: ... etc.

And when puzzled, Halt now and debug or inspect it go a long way in figuring things out.

As long as the method is intention revealing, what is the issue?

At the risk of some flames, Pharo isn't bound to some Smalltalk compatibility. And that is what is cool about it. We chose another path now we have to go our way of else.

Building on a great foundation is nice. But that doesn't equate to following the Smalltalk canon IMHO.

And now 64 bits becoming real with a nice FFI and pinned objects... that is going to bring in a lot of non smalltalk stuff for sure.

Phil

well, if continue on that, i think that while #ifEmpty: is perfectly fine, the #ifEmptyOrNil: are not. And indeed, in this case im also inclined to see those as pollution. Because uninitialized state can (or better to say - *must*) happen in one form - either it is nil, or empty collection, but not both. If your code having entry points that treats both of those as some kind of uninitialized state, then i would call it bad. To my opinion, it is bad practice to declare 'my method(s) can deal with any shit you can throw into it'. Personally, i prefer to clearly state what it accepting and what not, and strongly discourage any other free-form inputs, or even better - making them impossible to appear, so you don't have to put #ifEmptyOrNilOrCrazy: everywhere to make your code idioto-proof :) And the stupidity-proofing is quite simple, use converters/validators immediately on passed external data: myMethod: externalData myValidState := externalData asSanelyCheckedData. so, like that you don't have to put: myValidState ifValidState: [] everywhere :) Le 1 nov. 2016 15:14, "Igor Stasenko" <siguctua@gmail.com> a écrit :

...

On 1 November 2016 at 11:31, jtuchel@objektfabrik.de < jtuchel@objektfabrik.de> wrote:

...

Phil,

I see your point but disagree. I don't use Pharo regularly, so I cannot currently check if the implementation around this emptiness check is complete.

With complete I mean that following your logic, theere should be at least implementations of

ifEmpty: ifNotEmpty: ifEmpty:ifNotEmpty: ifEmptyOrNil: ifEmptyOrNil:otherwise:

why pollution? it just convenience method. mind you, that #isEmpty is also convenience method, without it you would do it like:

myArray size isZero ifTrue: [] of wait.. #isZero also convenience method... so if you elitist then you have to write it like that:

myArray size = 0 ifTrue: []

And that , to my opinion, adds even more pollution to the user code, because first, it is longer, and second #ifEmpty: much better clarifies the intent of author, comparing to size = 0

...

I really have to check for the size of collections very often, and the size of 1 is a very frequent case. So why not add:

ifExactlyOne: ifSizeIs:do: ifSizeIsGreaterThan:do:otherwiseDo:

You get the picture. I strongly believe this leads to pollution and ends up in a mess. We could save so much typing and make our programs so much more readable if we only were a bit more creative, right? ;-) A DSL is another story, though. If you write a Library that makes handling Collections nicer, this is okay and the methods are good to exist in its context. But they shouldn't necessarily all be part of the base image.

Don't get me wrong: if you and the Pharo community agree on lots of convenience methods, that is okay for me, and I find myself adding such methods to VA Smalltalk from time to time. I appreciate many of them being brought to VA ST in Grease.

Sometimes, this is simply a question of taste, sometimes it saves typing, sometimes it helps to improve readability of code.

But I wouldn't go so far to tell people they should better use such a method as a general advice. I would probably tell them: "look, here's a method I find much more elegant, you could *also* use that to save typing/increase readability".

Just my 2 cents, and highly off topic ;-)

Joachim

Am 01.11.16 um 08:43 schrieb phil@highoctane.be:

Because I grew tired of the isEmpty ifTrue: [ ] all over the place. And ifEmpty has the right semantics for my use cases (like assignment).

I do not really care about portability, I am doing Pharo only.

Phil

On Mon, Oct 31, 2016 at 5:30 PM, jtuchel@objektfabrik.de < jtuchel@objektfabrik.de> wrote:

...

Am 31.10.16 um 15:59 schrieb phil@highoctane.be:

but you should use myCollection ifEmpty: [ ... ]

interesting. Why do you think so? what if you wanted your code to be portable across Smalltalk dialects?

...

-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de <jtuchel@objektfabrik.de> Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

--

---

Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de <jtuchel@objektfabrik.de> Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

-- Best regards, Igor Stasenko.

-- Best regards, Igor Stasenko.

I guess you can circumvent the inlining by using perform (and selecting the code with "debug it" from the menu) as in: true perform: #ifTrue: with: [ 3 inspect ]  ----------------- Benoît St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero".  (A. Einstein) From: Nicolas Passerini <npasserini@gmail.com> To: Any question about pharo is welcome <pharo-users@lists.pharo.org> Sent: Monday, October 31, 2016 9:32 AM Subject: Re: [Pharo-users] How does Boolean ifTrue work? Well, in fact Boolean class has no instances, the boolean value true is an instance of True class, you should look at the ifTrue: methods in the subclasses of Boolean True and False.  But also, ifTrue: expressions are inlined, as the comment says in the code you posted. So I think that all this ifTrue: methods are never actually executed. 2016-10-31 14:17 GMT+01:00 CodeDmitry <dimamakhnin@gmail.com>: I am looking at ifTrue: alternativeBlock         "If the receiver is false (i.e., the condition is false), then the value is the         false alternative, which is nil. Otherwise answer the result of evaluating         the argument, alternativeBlock. Create an error notification if the         receiver is nonBoolean. Execution does not actually reach here because         the expression is compiled in-line."         self subclassResponsibility In order to perform the block, ifTrue must somehow end up evaluating the block, but this code only sends a subclassResponsibility message to itself and implicitly returns itself. Where does the block actually get evaluated? -- View this message in context: http://forum.world.st/How- does-Boolean-ifTrue-work- tp4920873.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.