January 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] On Twitter

by horrido

SRP has poster children. But seriously, Pharo is the "poster child". Seaside and Amber are the poster children representing the web. I'm focussed on Amber because I firmly believe that Smalltalk must have a good client-side story. The web is so important to the future of Smalltalk. Sven Van Caekenberghe-2 wrote > Yes I know, and it *is* an interesting project, for sure. > > But my remark was in the context of The Smalltalk Renaissance - does it > really fit ? Is it the best poster child ? -- View this message in context: http://forum.world.st/On-Twitter-tp4797177p4797863.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 5, 2015

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by kilon alios

I see , very interesting I will definitely take a look because obviously this something I want to use too . On Mon, Jan 5, 2015 at 3:44 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Exception handling is used a lot. > > Check senders of #on:do: > > 457 in my Pharo 3.0 > > That's not counting the 303 #ensure: that are used transparently in things > like: > > aFileRef readStreamDo: [ :s | s upToEnd ] > > Phil > > > On Mon, Jan 5, 2015 at 2:12 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > >> I dont know javascript well nor pharo but I am coming from python and for >> this scenario it would make more sense to me to use an exception than an >> actual check. At least that is the way Python deals with this situation >> which is an approach I really like. >> >> I know Pharo has exception handling as well, but unlike Python where >> exception handling is very popular I have barely seen it used by pharo >> coders. I am curious why . >> >> On Mon, Jan 5, 2015 at 3:01 PM, Sebastian Sastre < >> sebastian(a)flowingconcept.com> wrote: >> >>> >>> On Jan 5, 2015, at 10:38 AM, phil(a)highoctane.be wrote: >>> >>> In business apps, the need for default values happen all the time, so >>> the idiom has value (not sure for the message name though). >>> >>> >>> Totally. In real apps, having to compare against uninitialized variable >>> or nil as response or empty string happens so often that having this method >>> makes it quite convenient (AKA lots of code becomes one-liners). >>> >>> We could use >>> >>> x := [ self thing ] ifError: [ someDefault ] >>> >>> >>> I understand youâre setting a similar, quite not like it example but in >>> any case this one raises and catches an exception and that sounds quite >>> less efficient if compared to return self (when object is not nil and is >>> not an empty collection/string) >>> >>> for these purposes. Triggering errors is not too nice still. >>> >>> Now, what if self itself is nil or empty? >>> >>> BTW, isEmptyOrNil exists in the image for Collections and >>> UndefinedObject. Empty has no meaning for Object, so why test against empty >>> in the name? >>> >>> Note that is not a testing method, itâs a conditional executor of the >>> closure. >>> The reason why was already mentioned, is to allow you to write this >>> one-liner convenience: >>> someVar := self thing ifNilOrEmpty: [blah] >>> >>> `self thing` could be an expensive process that returns something or nil >>> or an empty collection. *If* you get nil or empty as result then you >>> would get the block values resulting in having blah at someVar >>> >>> >>> In the image, I see that we do have #default: anObject in several >>> places. It seems to serve the same intent. >>> >>> What is the idiom for such things in Pharo? Importing idioms from other >>> languages works but if we do have one already, we will introduce confusion. >>> >>> >>> how can you do that one-liner without introducing *ifNilOrEmpty:* ? >>> >>> >>> >>> Phil >>> >>> >>> >>> On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba <tudor(a)tudorgirba.com> >>> wrote: >>> >>>> This is not about taste. This is about not promoting the use of nil or >>>> dependency or the meaning of empty collection. >>>> >>>> A better way is to look at the upstream logic and modify that one so >>>> that it does not need to know about nil or empty. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre < >>>> sebastian(a)flowingconcept.com> wrote: >>>> >>>>> taste is taste but would you care to illustrate your point with >>>>> examples? >>>>> Iâm curious about it >>>>> >>>>> >>>>> >>>>> > On Jan 5, 2015, at 6:12 AM, stepharo <stepharo(a)free.fr> wrote: >>>>> > >>>>> > You summarise well the kind of code I do not like. >>>>> > isNil everywhere and horrible tests. >>>>> > >>>>> > Stef >>>>> > >>>>> > >>>>> > Le 4/1/15 23:27, Sebastian Sastre a Ã©crit : >>>>> >> Hi guys, >>>>> >> >>>>> >> Iâve started to use this little one: >>>>> >> >>>>> >> Object>>ifNilOrEmpty: aBlock >>>>> >> >>>>> >> self ifNil: [ ^ aBlock value ]. >>>>> >> >>>>> >> (self isCollection and: [ >>>>> >> self isEmpty ]) ifTrue: [ ^ aBlock value ]. >>>>> >> >>>>> >> ^ self. >>>>> >> >>>>> >> >>>>> >> It allows you to do the widely known JavaScript one-liner: >>>>> >> >>>>> >> var stuff = this.thing || âsome default value for when this.thing >>>>> is undefined, null or an empty stringâ. >>>>> >> >>>>> >> but in smalltalk in this way: >>>>> >> >>>>> >> stuff := self thing ifNilOrEmpty: [ âsome default value for when >>>>> self thing is nil or an empty stringâ ] >>>>> >> >>>>> >> simple thing feels practical and nice :) >>>>> >> >>>>> >> >>>>> >> >>>>> > >>>>> > >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >>> >>> >>> >>> >> > > > > >

Jan. 5, 2015

Re: [Pharo-dev] Old inspector and explorer

by Tudor Girba

Hi Sebastian, As I said, I do not see how your generic advice applies to the current situation. We went through concrete cases exactly to elucidate how people perceived the problems. If things would be as obvious as removing a click, we would not have this conversation, but it is not. That is why we have to talk about concrete scenarios. In the meantime, I addressed the two points raised in the thread: - adding dynamic variables to the Raw view, and - adding collection items in the Raw view. I will follow up with more details in the following days. Cheers, Doru On Mon, Jan 5, 2015 at 3:31 PM, Sebastian Sastre < sebastian(a)flowingconcept.com> wrote: > since youâre working on this I really wish you could make the links > yourself to get the right inspiration. You are the right guy for that. > > For everybody being critical of your own work is hard but is one of the > most valuable things you can have. The vulgar thing is the opposite (being > defensive) and thatâs the road to mediocrity. > > In any case, sure, I can take notes on usability and share it with you. > > As a start and concrete example take anything that now requires one extra > click or keystroke that before was not. > > > > On Jan 5, 2015, at 12:05 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Sebastian, > > I really do not see how your reply applies to the case at hand. > > If you have a concrete remark regarding how something is less useful now, > please feel free to make it. > > Cheers, > Doru > > > > On Mon, Jan 5, 2015 at 3:00 PM, Sebastian Sastre < > sebastian(a)flowingconcept.com> wrote: > >> +1 >> >> Remember that âoldâ also means that it *stands the test of time* >> >> We need to be careful while innovating with the basics (workspace, >> inspecting, navigating code and debugging) because that impacts the whole >> economy of using this technology. >> >> Make productivity go up, never down! >> >> One additional click doesnât sound like a lot but if that happens for >> something that you do 400 times a day is ~8000 times a month or ~60 minutes >> of clicking like crazy with overhead you didnât have before. >> >> UX is King. >> >> No way back from that, it really rules (the only thing we have in control >> is what kingdom will we invent for it to rule) >> >> >> >> >> On Dec 26, 2014, at 2:42 PM, stepharo <stepharo(a)free.fr> wrote: >> >> + 10000 >> >> Debugging the rendering loops of Athens was such an example. In Bloc I >> get some race conditions with MC forked process... another fun one. >> Let people decide!!! >> >> Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! >> I WANT to DECIDE WHEN. I control my agenda and my own schedule and my >> list is huge. >> >> >> Stef >> >> Doru, >> >> I think your intention is a good one but slightly misplaced. I really >> like the idea of GTInspector. It surely is a great tool and maybe I'll >> start to build my own inspector on my kind of things. >> To me the difference is between "motivated to do" or "forced to do". Most >> of the time we are trying hard to solve our own problems. If in that >> progress other problems are forced upon us we get easily distracted and >> frustrated. The same goes for new tools. If I'm forced to use these it just >> means I have to deal with it first and only then I'm allowed to deal with >> my own problem. As it was in that special case the bug in nautilus and the >> new inspector made me shy away from developing something in 4.0 and now I'm >> back on 3.0. >> >> So I think the only possibility is to "offer" a new way of doing things >> and give people time to adjust. >> >> Norbert >> >> Am 26.12.2014 um 13:18 schrieb Tudor Girba <tudor(a)tudorgirba.com>: >> >> Hi, >> >> I think there must be a misunderstanding. >> >> There can be a good reason for having a basic inspector around, but I >> think the reason is not because people cannot choose what to use. >> >> There is a toggle to enable/disable the GTInspector. But, even without >> it, the main feature of the GTInspector is exactly to be extended the way >> people want and not impose a fixed way. This is completely different from >> what existed before. In fact, half a year ago there was no problem that >> people could neither choose nor extend anything. In the meantime, we can >> extend our workflows significantly. Adding the various flavors of browsing >> objects is perhaps a couple of lines long and each of us can tweak it >> because there is no higher entity that should decide anymore. >> >> What I cannot quite grasp is that while we pride ourselves with working >> on a reflective language, when we have reflective tools, we seem to not be >> able to take half an hour to build the tool that fits our needs. I am >> still wondering what is needed to improve this. I think that it's a problem >> of exercise or of communication, but it seems that just providing the >> examples that I linked before is not enough and most people look at the >> inspector still as a black box tool. I will try to work on a tutorial to >> see if it gets better, but do you find the moldability proposition not >> valuable or just unclear? >> >> But, as I said, there can still be a valid reason to enable a basic >> inspector that relies on a minimal of libraries (so, definitely not the >> Spec one) for the same reason we have an emergency debugger. >> >> Cheers, >> Doru >> >> >> On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo(a)free.fr> wrote: >> >>> I will add basicInspect in Object so that we can get access to the old >>> inspector. >>> I like that people can choose their tools! >>> I mentioned that 20 times but people do not care apparently. >>> >>> Stef >>> >>> Le 23/12/14 11:50, Norbert Hartl a Ã©crit : >>> >>> Is there a way to get the old tools via shortcut? >>>> >>>> I started something new with pharo 4.0 today. I discovered a bug in >>>> Nautilus where every rename or deletion of a method raises a debugger. I >>>> tried finding the bug but struggled because to me the new inspector is >>>> really confusing. If I "just" want to unfold a few levels of references to >>>> get a glimpse of the structure the new tool prevents me from doing that. >>>> There is just to much information in this window and too much happening to >>>> me. >>>> To me it looks like a power tool you need to get used to. So it is >>>> probably not the best tool for simple tasks and people new to this >>>> environment might be overwhelmed. At least I would like to be able to use >>>> the old tools. >>>> >>>> Norbert >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 5, 2015

Re: [Pharo-dev] Old inspector and explorer

by kilon alios

I agree completely , Dorus has been a very good listener to criticism and he has changed things on popular request. Asking for concrete examples instead of falling down the trap of discussing general philosophies and ideologies is the way to go. On Mon, Jan 5, 2015 at 4:59 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 05 Jan 2015, at 15:31, Sebastian Sastre <sebastian(a)flowingconcept.com> > wrote: > > > > since youâre working on this I really wish you could make the links > yourself to get the right inspiration. You are the right guy for that. > > > > For everybody being critical of your own work is hard but is one of the > most valuable things you can have. The vulgar thing is the opposite (being > defensive) and thatâs the road to mediocrity. > > > > In any case, sure, I can take notes on usability and share it with you. > > > > As a start and concrete example take anything that now requires one > extra click or keystroke that before was not. > > Doru is anything but defensive. He literally asks for concrete examples. > The goal is to make the workflow better for everyone. > > >> On Jan 5, 2015, at 12:05 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> > >> Hi Sebastian, > >> > >> I really do not see how your reply applies to the case at hand. > >> > >> If you have a concrete remark regarding how something is less useful > now, please feel free to make it. > >> > >> Cheers, > >> Doru > >> > >> > >> > >> On Mon, Jan 5, 2015 at 3:00 PM, Sebastian Sastre < > sebastian(a)flowingconcept.com> wrote: > >> +1 > >> > >> Remember that âoldâ also means that it stands the test of time > >> > >> We need to be careful while innovating with the basics (workspace, > inspecting, navigating code and debugging) because that impacts the whole > economy of using this technology. > >> > >> Make productivity go up, never down! > >> > >> One additional click doesnât sound like a lot but if that happens for > something that you do 400 times a day is ~8000 times a month or ~60 minutes > of clicking like crazy with overhead you didnât have before. > >> > >> UX is King. > >> > >> No way back from that, it really rules (the only thing we have in > control is what kingdom will we invent for it to rule) > >> > >> > >> > >> > >>> On Dec 26, 2014, at 2:42 PM, stepharo <stepharo(a)free.fr> wrote: > >>> > >>> + 10000 > >>> > >>> Debugging the rendering loops of Athens was such an example. In Bloc I > get some race conditions with MC forked process... another fun one. > >>> Let people decide!!! > >>> > >>> Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! > >>> I WANT to DECIDE WHEN. I control my agenda and my own schedule and my > list is huge. > >>> > >>> > >>> Stef > >>>> Doru, > >>>> > >>>> I think your intention is a good one but slightly misplaced. I really > like the idea of GTInspector. It surely is a great tool and maybe I'll > start to build my own inspector on my kind of things. > >>>> To me the difference is between "motivated to do" or "forced to do". > Most of the time we are trying hard to solve our own problems. If in that > progress other problems are forced upon us we get easily distracted and > frustrated. The same goes for new tools. If I'm forced to use these it just > means I have to deal with it first and only then I'm allowed to deal with > my own problem. As it was in that special case the bug in nautilus and the > new inspector made me shy away from developing something in 4.0 and now I'm > back on 3.0. > >>>> > >>>> So I think the only possibility is to "offer" a new way of doing > things and give people time to adjust. > >>>> > >>>> Norbert > >>>> > >>>>> Am 26.12.2014 um 13:18 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > >>>>> > >>>>> Hi, > >>>>> > >>>>> I think there must be a misunderstanding. > >>>>> > >>>>> There can be a good reason for having a basic inspector around, but > I think the reason is not because people cannot choose what to use. > >>>>> > >>>>> There is a toggle to enable/disable the GTInspector. But, even > without it, the main feature of the GTInspector is exactly to be extended > the way people want and not impose a fixed way. This is completely > different from what existed before. In fact, half a year ago there was no > problem that people could neither choose nor extend anything. In the > meantime, we can extend our workflows significantly. Adding the various > flavors of browsing objects is perhaps a couple of lines long and each of > us can tweak it because there is no higher entity that should decide > anymore. > >>>>> > >>>>> What I cannot quite grasp is that while we pride ourselves with > working on a reflective language, when we have reflective tools, we seem to > not be able to take half an hour to build the tool that fits our needs. I > am still wondering what is needed to improve this. I think that it's a > problem of exercise or of communication, but it seems that just providing > the examples that I linked before is not enough and most people look at the > inspector still as a black box tool. I will try to work on a tutorial to > see if it gets better, but do you find the moldability proposition not > valuable or just unclear? > >>>>> > >>>>> But, as I said, there can still be a valid reason to enable a basic > inspector that relies on a minimal of libraries (so, definitely not the > Spec one) for the same reason we have an emergency debugger. > >>>>> > >>>>> Cheers, > >>>>> Doru > >>>>> > >>>>> > >>>>> On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo(a)free.fr> wrote: > >>>>> I will add basicInspect in Object so that we can get access to the > old inspector. > >>>>> I like that people can choose their tools! > >>>>> I mentioned that 20 times but people do not care apparently. > >>>>> > >>>>> Stef > >>>>> > >>>>> Le 23/12/14 11:50, Norbert Hartl a Ã©crit : > >>>>> > >>>>> Is there a way to get the old tools via shortcut? > >>>>> > >>>>> I started something new with pharo 4.0 today. I discovered a bug in > Nautilus where every rename or deletion of a method raises a debugger. I > tried finding the bug but struggled because to me the new inspector is > really confusing. If I "just" want to unfold a few levels of references to > get a glimpse of the structure the new tool prevents me from doing that. > There is just to much information in this window and too much happening to > me. > >>>>> To me it looks like a power tool you need to get used to. So it is > probably not the best tool for simple tasks and people new to this > environment might be overwhelmed. At least I would like to be able to use > the old tools. > >>>>> > >>>>> Norbert > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> www.tudorgirba.com > >>>>> > >>>>> "Every thing has its own flow" > >>>> > >>> > >> > >> > >> > >> > >> -- > >> www.tudorgirba.com > >> > >> "Every thing has its own flow" > > > > >

Jan. 5, 2015

Re: [Pharo-dev] Old inspector and explorer

by Sebastian Sastre

> On Jan 5, 2015, at 12:59 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 05 Jan 2015, at 15:31, Sebastian Sastre <sebastian(a)flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote: >> >> since youâre working on this I really wish you could make the links yourself to get the right inspiration. You are the right guy for that. >> >> For everybody being critical of your own work is hard but is one of the most valuable things you can have. The vulgar thing is the opposite (being defensive) and thatâs the road to mediocrity. >> >> In any case, sure, I can take notes on usability and share it with you. >> >> As a start and concrete example take anything that now requires one extra click or keystroke that before was not. > > Doru is anything but defensive. He literally asks for concrete examples. The goal is to make the workflow better for everyone. I saw that, he doesnât even need your defence :) I was reminding that to all of us because I want to see us doing more great work :)

Jan. 5, 2015

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by Sebastian Sastre

Ah Henry but you are making the code to know if itâs a collection or not, I talking about making the code specifically to ignore that. Why that would lead to "bad code"? can you elaborate or put examples instead of adjectives? > On Jan 5, 2015, at 1:02 PM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > No, I'm talking about exactly what I quoted, implementing ifNilOrEmpty: on just UndefinedObject/Collection, but not Object. > Doing that is not about indoctrinating, but preventing bad code resulting from using the same variable to hold non-polymorphic objects. > >> >> Whatever the case does your idea pass this test? >> >> testIfNilOrEmpty >> >> | stuff thing | >> >> stuff := nil. >> >> self assert: stuff equals: nil. >> self assert: thing equals: nil. >> thing := stuff ifNilOrEmpty: [ 42 ]. >> self assert: thing equals: 42. >> >> stuff := 1984. >> thing := stuff ifNilOrEmpty: [ 42 ]. >> >> self deny: thing = nil. >> self assert: thing equals: 1984. >> self deny: thing = 42. > > Of course, since my idea was to use ifNil: when the variable you are dealing with is not Collections.

Jan. 5, 2015

Re: [Pharo-dev] On Twitter

by Sven Van Caekenberghe

> On 05 Jan 2015, at 16:09, phil(a)highoctane.be wrote: > > > > On Mon, Jan 5, 2015 at 3:57 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 05 Jan 2015, at 15:28, horrido <horrido.hobbies(a)gmail.com> wrote: > > > > You're quite right. I guess I should focus on *one thing* right now before it > > gets lost in the shuffle: Complete and publish my Amber tutorial. I have a > > lot of work ahead of me in this one. > > Not that I have anything against Amber, but why pick that one ? > > Everybody seems to think something along the lines of 'JavaScript is very popular, if only we get on that platform and we'll be all set' - I don't think that is the case. Even Amber's original developer is now working full time on JavaScript, yet does no longer seem to use it. > > Hey, Amber is alive! 0.14 just out. Herby does a good job, examples are refined, we are injecting effort in it. Yes I know, and it *is* an interesting project, for sure. But my remark was in the context of The Smalltalk Renaissance - does it really fit ? Is it the best poster child ? > It takes a while to get things to 1.0. We can't afford to pass on SPAs and it is not with Seaside that we'll do it. > > > Also, on technical grounds it could be argued that Amber misses a number of critical Smalltalk features (thisContext, #become:). Furthermore, it is slower and has a only a limited IDE. > > thisContext and become: aren't in but even like that, the prototyping power of Amber is strong even if tooling can be improved (first the core, then the bells and whistles). > > Javascript also has features that Smalltalk doesn't have. So, it is a give or take game. > If anything, Amber helps one into understanding the current Javascript ways in a quite good manner. It does for me. > > > Other than that, focus is good. > > > For the time being, I'll cut back on my tweets and Facebook and Google+.

Jan. 5, 2015

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by Norbert Hartl

> Am 05.01.2015 um 15:22 schrieb Sebastian Sastre <sebastian(a)flowingconcept.com>: > >> >> On Jan 5, 2015, at 12:00 PM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >> >>> >>> Am 05.01.2015 um 14:43 schrieb Sebastian Sastre <sebastian(a)flowingconcept.com <mailto:sebastian@flowingconcept.com>>: >>> >>> one hugely typical case is having the model of an input that has either nil because is pristine or an empty string and the app needs to guarantee some default value that should not be nil or an empty string. >>> >>> Another frequent case is the response of some API that will typically answer nil or an empty collection when something is not found and you want to guarantee some value or model that should not be nil or an empty collection. >>> >>> About #thing being meaningless, sure, Iâve mentioned as general example. I donât see that every user of #thing has to use the ifNilOrEmpty:, only those who care about guaranteeing that closure valued if none is found which is expressed in the completely sensible form of receiving nil or an empty collection :) >>> >> My point is that as long as you do not promise a certain type of object you will have to deal with the uncertainty what methods you can call on that object of uncertain type. By not using a check you just extend the life of this uncertainty a while longer (bad if the user of your code has to deal with it). Some has to deal with it if the object has to do something. And the earlier this uncertainty is removed the better it is. At least in my opinion. >> >> Norbert > > Ah! I understand your point better now, thanks for clarifying. Actually you helped me to understand better something I systematically do often which is extending that uncertainty as much as is convenient :) > > For example Mapless <http://sebastianconcept.github.io/Mapless> (and MiniMapless <https://github.com/flow-stack/MiniMapless>) gives you the freedom of not having to predict what instance variables your persistent objects will have and still gives you the features now. > > Is the opposite of the predictive certainty demanded by typed technologies and their the compiler is your friend BS that completely frustrates your creative flow. > > Dynamic technologies are all about delaying certainty. Late binding is delaying it until runtime. I donât say this as a technicality, I see it as a useful tool to push the present into the future and pull the future into the present. > I think I need to be more clear on this. With type I meant a set of methods I can call on an object. You can name it protocol or interface or duck type. With certainty I meant that a method #thing has to give a promise about a certain type (it returns) so you know what you can call on that object. Without knowing the type you can only invoke the set of methods defined in Object or you can use objects as structs. To build objects that serve a specific purpose you need to establish communication ways (methods and calls) that exceed that. It's all about communication after all. So I would say you need to establish certainty at coding time (using interfaces and objects). Late binding postpones the specific implementation of your type that make it possible to have plenty of use cases managed. Norbert > Being able to reflect in real-time makes this possible. > > Is what makes easier to invent the future when they âtouch" each other. > > If someone else has to deal with the object and code with this uncertainty, you know youâre on the right place for personal mastery <http://www.cs.virginia.edu/~cs655/readings/smalltalk.html> to happen since Smalltalk was designed to allow the individual to easily navigate code and master the system by itself. > > This is actually a major reason to choose Smalltalk. > > Thanks again!

Jan. 5, 2015

Re: [Pharo-dev] On Twitter

by phil＠highoctane.be

On Mon, Jan 5, 2015 at 3:57 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 05 Jan 2015, at 15:28, horrido <horrido.hobbies(a)gmail.com> wrote: > > > > You're quite right. I guess I should focus on *one thing* right now > before it > > gets lost in the shuffle: Complete and publish my Amber tutorial. I > have a > > lot of work ahead of me in this one. > > Not that I have anything against Amber, but why pick that one ? > > Everybody seems to think something along the lines of 'JavaScript is very > popular, if only we get on that platform and we'll be all set' - I don't > think that is the case. Even Amber's original developer is now working full > time on JavaScript, yet does no longer seem to use it. > Hey, Amber is alive! 0.14 just out. Herby does a good job, examples are refined, we are injecting effort in it. It takes a while to get things to 1.0. We can't afford to pass on SPAs and it is not with Seaside that we'll do it. > Also, on technical grounds it could be argued that Amber misses a number > of critical Smalltalk features (thisContext, #become:). Furthermore, it is > slower and has a only a limited IDE. thisContext and become: aren't in but even like that, the prototyping power of Amber is strong even if tooling can be improved (first the core, then the bells and whistles). Javascript also has features that Smalltalk doesn't have. So, it is a give or take game. If anything, Amber helps one into understanding the current Javascript ways in a quite good manner. It does for me. > Other than that, focus is good. > > > For the time being, I'll cut back on my tweets and Facebook and Google+. > > >

Jan. 5, 2015

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by Henrik Johansen

> On 05 Jan 2015, at 3:46 , Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > > >> On Jan 5, 2015, at 12:07 PM, Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: >> >> >>> On 05 Jan 2015, at 12:06 , Sebastian Sastre <sebastian(a)flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote: >>> >>> but not putting it on Object would change the feature since you do want it returning self on that case. >> >> No. In that case, you want to use ifNil: , not ifNilOrEmpty:. >> The only thing Object >> ifNilOrEmpty would support, is putting both collections and non-collection in the same variable, which is usually a bad idea to begin with, >> since it will lead to "are you a collection or single instance?" checks in almost every user of said variable. >> > > Hi Henry, > > I think you are talking of a different feature or maybe promoting that things should not be treated as possibly nil or empty collections which is understandable but Iâm treating the programers as good citizens that know what they do and bear the consequences (not as beasts that should be educated or indoctrinated or prevented on how to use code and do things) No, I'm talking about exactly what I quoted, implementing ifNilOrEmpty: on just UndefinedObject/Collection, but not Object. Doing that is not about indoctrinating, but preventing bad code resulting from using the same variable to hold non-polymorphic objects. > > Whatever the case does your idea pass this test? > > testIfNilOrEmpty > > | stuff thing | > > stuff := nil. > > self assert: stuff equals: nil. > self assert: thing equals: nil. > thing := stuff ifNilOrEmpty: [ 42 ]. > self assert: thing equals: 42. > > stuff := 1984. > thing := stuff ifNilOrEmpty: [ 42 ]. > > self deny: thing = nil. > self assert: thing equals: 1984. > self deny: thing = 42. Of course, since my idea was to use ifNil: when the variable you are dealing with is not Collections. Cheers, Henry

Jan. 5, 2015