February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Are Objects really hard?

by Guido Stepken

I did analyse some of these "memory pumping effects" in Pharo. Come from overuse of "inheritance", that causes big objects with hundreds of methods to be created and garbaged, just for short tasks. Better: "Composition over inheritance"!!! Second problem is the "Liskov problem": Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T. See PetitParser. Universal Tool. Fine. Blowing up memory unnecessarily. Moose ... ugh. These *are* design flaws. best, have fun, Guido Stepken Am 13.02.2012 14:20 schrieb "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu>: > There is no question that over-use of inheritance (failure to understand > composition) is a classic beginner mistake. That said, don't underestimate > the value of inheritance. Granted, the example I have in mind is perfect > for specialization, but beyond that, failure to use (extensive) inheritance > can at times lead to lots of duplicate code (which is really bad). Say it > once - inheritance can help one do just that (policy up, implementation > down, etc.). > > Bill > > >

Feb. 13, 2012

Re: [Pharo-project] Debugger hanging... was Re: 1.4 - better from Jenkins

by Igor Stasenko

On 13 February 2012 12:55, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Feb 10, 2012, at 6:42 PM, Ben Coman wrote: > >> While I was working towards implementing DosFileDirectory>>preferencesFolder & >>preferencesGeneralFolder >> I was stepping through: SmalltalkImage>>snapshot:andQuit: did a: <Restart> >> and then stepped down to: Â Cursor write show >> at which point the debugger hung the image. >> >> Now I guess theres an equal chance this is not really an issue as something "special" might be happening here straddling the save point. Â Just thought I would report it for review. >> >> To reproduce on non-Windows you could probably set preferencesFolder & preferencesGeneralFolder on your platform to self shouldBeImplemented and proceed from the debugger that comes up. >> >> SmalltalkImage>>snapshot: save andQuit: quit >> Â | snapshotResult resuming startupErrors | >> Â Object flushDependents. >> Â Object flushEvents. >> Â self addSnapshotRecord: save andQuit: quit. >> Â self processShutDownList: quit. >> Â Cursor write show. Â <--------Image Hangs Here after a <Restart> of the method while debugging following a resume.. >> >> cheers, -ben > > IIRC, the InputEventSensor is deregistered as part of shutdown, if so, that would indeed lead to a non-responsive image at that point. (In the sense that the thing that processes input is no longer there) > Well, its #shutDown method is empty. But still, i think you have right insight. Because there is enough of Delay>>shutDown to stop everything, because most stuff using delays , including UI process. ---- shutDown "Suspend the active delay, if any, before snapshotting. It will be reactived when the snapshot is resumed." "Details: This prevents a timer interrupt from waking up the active delay in the midst snapshoting, since the active delay will be restarted when resuming the snapshot and we don't want to process the delay twice." > Cheers, > Henry -- Best regards, Igor Stasenko.

Feb. 13, 2012

Re: [Pharo-project] [squeak-dev] Re: Are Objects really hard?

by Tudor Girba

Hi, 2012/2/13 GÃ¶ran Krampe <goran(a)krampe.se>: > On 02/13/2012 12:22 PM, Sven Van Caekenberghe wrote: >> >> >> On 13 Feb 2012, at 10:23, GÃ¶ran Krampe wrote: >> >>> PS. Why oh why did Pharo lose the "double click on ? in the class browser >>> to see inheritance textually"-mechanism? :) >> >> >> I just tried in my 1.4 image #14329 image with the standard browser and it >> works: > > > Oh nice! I confess i didn't try the latest Pharo (only 1.2) before I wrote > this - I just presumed it still did not work ;) My bad. I could not resist: One should not presume much about Pharo because its evolution super-linear, and we all know how poor we are at estimating such super linear models. Cheers, Doru > regards, GÃ¶ran > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 13, 2012

Re: [Pharo-project] [squeak-dev] Re: Are Objects really hard?

by GÃ¶ran Krampe

On 02/13/2012 12:22 PM, Sven Van Caekenberghe wrote: > > On 13 Feb 2012, at 10:23, GÃ¶ran Krampe wrote: > >> PS. Why oh why did Pharo lose the "double click on ? in the class browser to see inheritance textually"-mechanism? :) > > I just tried in my 1.4 image #14329 image with the standard browser and it works: Oh nice! I confess i didn't try the latest Pharo (only 1.2) before I wrote this - I just presumed it still did not work ;) My bad. regards, GÃ¶ran

Feb. 13, 2012

Re: [Pharo-project] Are Objects really hard?

by Schwab,Wilhelm K

There is no question that over-use of inheritance (failure to understand composition) is a classic beginner mistake. That said, don't underestimate the value of inheritance. Granted, the example I have in mind is perfect for specialization, but beyond that, failure to use (extensive) inheritance can at times lead to lots of duplicate code (which is really bad). Say it once - inheritance can help one do just that (policy up, implementation down, etc.). Bill

Feb. 13, 2012

Re: [Pharo-project] Debugger hanging... was Re: 1.4 - better from Jenkins

by Henrik Johansen

On Feb 10, 2012, at 6:42 PM, Ben Coman wrote: > While I was working towards implementing DosFileDirectory>>preferencesFolder & >>preferencesGeneralFolder > I was stepping through: SmalltalkImage>>snapshot:andQuit: did a: <Restart> > and then stepped down to: Cursor write show > at which point the debugger hung the image. > > Now I guess theres an equal chance this is not really an issue as something "special" might be happening here straddling the save point. Just thought I would report it for review. > > To reproduce on non-Windows you could probably set preferencesFolder & preferencesGeneralFolder on your platform to self shouldBeImplemented and proceed from the debugger that comes up. > > SmalltalkImage>>snapshot: save andQuit: quit > | snapshotResult resuming startupErrors | > Object flushDependents. > Object flushEvents. > self addSnapshotRecord: save andQuit: quit. > self processShutDownList: quit. > Cursor write show. <--------Image Hangs Here after a <Restart> of the method while debugging following a resume.. > > cheers, -ben IIRC, the InputEventSensor is deregistered as part of shutdown, if so, that would indeed lead to a non-responsive image at that point. (In the sense that the thing that processes input is no longer there) Cheers, Henry

Feb. 13, 2012

Re: [Pharo-project] Are Objects really hard?

by Sven Van Caekenberghe

On 13 Feb 2012, at 10:23, GÃ¶ran Krampe wrote: > PS. Why oh why did Pharo lose the "double click on ? in the class browser to see inheritance textually"-mechanism? :) I just tried in my 1.4 image #14329 image with the standard browser and it works: ProtoObject #() Object #() Magnitude #() LookupKey #('key') Association #('value') Sven

Feb. 13, 2012

Re: [Pharo-project] Regular expression

by Gary Chambers

'a1b' matchesRegex: '[[:alnum:]]*((\d+[[:alnum:]]*[[:alpha:]]+)|([[:alpha:]]+[[:alnum:]]*\d+))[[:alnum:]]*'. perhaps? Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, February 12, 2012 2:40 PM Subject: Re: [Pharo-project] Regular expression thanks for the update. Now may be the problem can be still express with regex. Stef On Feb 12, 2012, at 10:49 AM, Lukas Renggli wrote: > VB-Regexp does not support any of the following common regular > expression features: lookahead, lookbehind, recursion, multiplicity > ranges, non-greedy quantifier, shy groups, directives, conditionals, > named captures, back references, and comments. > > You can (conceptually) do all this with PetitParser, but then you are > not writing a regular expression anymore but a (PEG) parser. > > There was once a plugin that called an external regular expression > library (I think it used the library Perl is using) that supported the > features you are looking for. > > Lukas > > On 11 February 2012 23:27, <recursive68(a)gmail.com> wrote: >> Hi, >> >> Is it possible to use the VB-Regexp package to construct a single regular >> expression that ensures a string is alphanumeric and contains both at >> least >> one number and alphabetic character. >> >> Looking at the regexp package and documentation it doesn't appear so. In >> javascript or perl you use something like this with lookahead assertions: >> >> ^(?=.*[a-zA-Z])(?=.*[0-9]).*$ >> >> I have something working using multiple regexp's but wondered if a more >> typical regexp was possible using the package ? >> >> Thanks >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch >

Feb. 13, 2012

Re: [Pharo-project] [squeak-dev] Re: Are Objects really hard?

by Frank Shearar

2012/2/13 GÃ¶ran Krampe <goran(a)krampe.se>: > Hi all Smalltalkers! > > Only cross posting to squeak and pharo (communities I know), because this > turned into a long post. But try reading it - I hope it is both fun and > perhaps interesting. :) > > > On 02/11/2012 01:21 PM, Janko MivÅ¡ek wrote: >> >> Hi guys, >> >> Again one interesting topic for this weekend to discuss. David Nolen, a >> Lisp and JavaScript guy posted in his blog an article titled Illiterate >> Programming [1] where he said: >> >> "...Yet I think Smalltalk still fundamentally failed (remember this is a >> programming language originally designed to scale from children to >> adults) because *Objects are really hard* and no-one really understands >> to this day how to do them right...." > > > As Hernan pointed out - it is programming that is hard, not *objects* per > se. While that is true, one can of course still reflect on the aspects of OO > and why people *perceive* it as hard. > > SIDENOTE: As Milan wrote later in the thread - the patterns movement that > Kent Beck started together with the Gang of Four led to the creation of TONS > of books fully packed with OO designs in various domains. So yes, there is > an *abundance* of books on OO design to find *iff* one goes looking for it. > > >> He links to Alan Kay post [2] back in 1998 where he talks about problems >> with inheritance: >> >> "Here are a few problems in the naive inheritance systems we use today: >> confusions of Taxonomy and Parentage, of Specialization and Refinement, >> of Parts and Wholes, of Semantics and Pragmatics..." > > > Of all OO mechanisms most agree that inheritance is the one that gets abused > the most... if we disregard the "abuse" one can find in so called OO code > that stems from it not being OO at all :) > > Alan writes "confusions" and I suspect he carefully avoids saying one is > wrong and the other is right, because its not that simple. Truth is one can > use inheritance differently - as long as it makes your life better it can't > really be argued to be "wrong". :) > > I think most OO developers goes through some "ladder of enlightenment" going > something like this: > > 0. You really have no clue and tend to confuse composition "parts and whole" > with inheritance. You just create a mess. Perhaps you avoid this mess by > reading a book or attending an OO course, but hey, who does that in 2012? > ;). But let's say you *do* read a book - proceed to level 1... > > 1. You get all into Animals and other "inheritance" examples mirroring the > real world. Perhaps you get totally sucked into the "mirror the real > world"-idea. Thus, you try desperately to find "ISA" relations among the > domain objects and use those for inheritance, without really thinking *why* > that is a good idea. And sure, it often gets it fairly right so it's a huge > step forward. But let's pretend you now have coded quite a bit and thus > proceeds to level 2 :) > > 2. Specialization. After some time you start to understand polymorphism and > the substitution principle etc, so instead of blindly testing if "A isa B" > sounds right in your ears you start thinking in terms of generalisation and > specialization. And you see objects in your head. You talk about them as if > they are concrete and you can hold them in your hand etc. Perhaps you even > draw them on whiteboards and envision them in different scenarios "talking > to each other". If you use a statically typed language this is where your > road stops :). You end up writing fairly good code, but your inheritance > will probably be totally focused on enabling polymorphism between objects, > which of course is not all bad. But hey, after a few years of Smalltalking - > proceed to level 3. > > 3. As a seasoned Smalltalker you eventually come down from your "OO rush" > and realize that... hey, wait a minute! Polymorphism is not *tied* to class > inheritance (unless you are trapped in some static type system). In fact, > you realize that class inheritance in Smalltalk is "merely" a nice way of > reducing the redundancy of code by creating dependencies between separate > abstractions of code. This realization enables you to use inheritance in a > more liberal fashion - which probably means you tend to use it *less*. And > instead you tend to "add more objects" and use composition of objects more > and more, relying on brittle deep hierarchies of inheritance less and less. Well, we like to look at Java and hold our noses, but really, Java has a rubbish type system, regardless of it being static. Now if you were looking at some Haskell code, you'd see some highly polymorphic stuff going on thanks to typeclasses. And in the dynamic functional language corner you'd recognise good Smalltalk practice in Clojure's Protocols. (They like to say that protocols solve the Expression Problem, but really, it's multimethods that do that, not protocols.) If you'd like to see Clojure's protocols in action, this is a nice demonstration: http://news.ycombinator.com/item?id=3515862 The thing to bear in mind here is that (a) protocols won't surprise you; they're "this thing responds to this set of messages" just as you'd expect and (b) they do not pollute the global namespace: you can add a method to some object _in a scoped manner_. > SIDENOTE: A really cool example of how powerful object composition is: > PetitParser by Lukas. For years we have been creating parsers by generating > code from specifications and suddenly Lukas decides that hey, why not > instead *compose* a parser from ...objects? It is so obvious in retrospect, > but the result is a tremendously nicer and more powerful way of constructing > parsers. But you realise the irony here, right? That if you google "parser combinator" you hit all those "non-OO" languages like Haskell (and then the new kids like Scala and F#). (Yes, yes, 3rd hit's Gilad's talk. Not surprising.) But then, that in itself isn't terribly surprising, because not many people get at a deep level that objects are nothing more than higher order functions that close over variables. I have a long-running argument with a colleague who says (among other reasons) that he thinks Smalltalk is rubbish because class-based systems are rubbish (because of all the issues around inheritance). But, of course, while we happen to use classes all the time, we don't HAVE to. And, indeed, there are several prototype-based Smalltalk libraries. Because, at its core, Smalltalk isn't about classes, it's about objects sending messages to each other. > You also conclude that while you *can* reuse behaviors and compose behaviors > using inheritance you are also aware that inheritance creates a life cycle > *dependency* between classes that you *may* or *may not* want to have. Class > inheritance is a brittle relation. Thus, even if class A *can* inherit from > B, you might decide not to - because you anticipate that the development > lineage will diverge, or perhaps you have no control over A (library? other > developer? bad code?), and you do not want that dependency. But the up side > is that sometimes you *really* want that dependency, change superclass and > bam - affect all subclasses. Indeed: you should probably only use inheritance if you _have to_. Exactly because it couples every class in an hierarchy together, and you can no longer understand a method without understanding how that method overrides/replaces/is overridden/is replaced in the tree. > Another obvious benefit of inheritance is of course "documentation > structure" that you and other developers can understand. I'm sure we can do much better though. I'm thinking here of "this is a Stream because it understands <set of standard Stream messages>". frank > ...well. Of course, the above was written sloppily and can of course be > refined or totally shot down. Feel free to do both! :) > > regards, GÃ¶ran > > PS. Why oh why did Pharo lose the "double click on ? in the class browser to > see inheritance textually"-mechanism? :) >

Feb. 13, 2012

Re: [Pharo-project] Are Objects really hard?

by GÃ¶ran Krampe

Hi all Smalltalkers! Only cross posting to squeak and pharo (communities I know), because this turned into a long post. But try reading it - I hope it is both fun and perhaps interesting. :) On 02/11/2012 01:21 PM, Janko MivÅ¡ek wrote: > Hi guys, > > Again one interesting topic for this weekend to discuss. David Nolen, a > Lisp and JavaScript guy posted in his blog an article titled Illiterate > Programming [1] where he said: > > "...Yet I think Smalltalk still fundamentally failed (remember this is a > programming language originally designed to scale from children to > adults) because *Objects are really hard* and no-one really understands > to this day how to do them right...." As Hernan pointed out - it is programming that is hard, not *objects* per se. While that is true, one can of course still reflect on the aspects of OO and why people *perceive* it as hard. SIDENOTE: As Milan wrote later in the thread - the patterns movement that Kent Beck started together with the Gang of Four led to the creation of TONS of books fully packed with OO designs in various domains. So yes, there is an *abundance* of books on OO design to find *iff* one goes looking for it. > He links to Alan Kay post [2] back in 1998 where he talks about problems > with inheritance: > > "Here are a few problems in the naive inheritance systems we use today: > confusions of Taxonomy and Parentage, of Specialization and Refinement, > of Parts and Wholes, of Semantics and Pragmatics..." Of all OO mechanisms most agree that inheritance is the one that gets abused the most... if we disregard the "abuse" one can find in so called OO code that stems from it not being OO at all :) Alan writes "confusions" and I suspect he carefully avoids saying one is wrong and the other is right, because its not that simple. Truth is one can use inheritance differently - as long as it makes your life better it can't really be argued to be "wrong". :) I think most OO developers goes through some "ladder of enlightenment" going something like this: 0. You really have no clue and tend to confuse composition "parts and whole" with inheritance. You just create a mess. Perhaps you avoid this mess by reading a book or attending an OO course, but hey, who does that in 2012? ;). But let's say you *do* read a book - proceed to level 1... 1. You get all into Animals and other "inheritance" examples mirroring the real world. Perhaps you get totally sucked into the "mirror the real world"-idea. Thus, you try desperately to find "ISA" relations among the domain objects and use those for inheritance, without really thinking *why* that is a good idea. And sure, it often gets it fairly right so it's a huge step forward. But let's pretend you now have coded quite a bit and thus proceeds to level 2 :) 2. Specialization. After some time you start to understand polymorphism and the substitution principle etc, so instead of blindly testing if "A isa B" sounds right in your ears you start thinking in terms of generalisation and specialization. And you see objects in your head. You talk about them as if they are concrete and you can hold them in your hand etc. Perhaps you even draw them on whiteboards and envision them in different scenarios "talking to each other". If you use a statically typed language this is where your road stops :). You end up writing fairly good code, but your inheritance will probably be totally focused on enabling polymorphism between objects, which of course is not all bad. But hey, after a few years of Smalltalking - proceed to level 3. 3. As a seasoned Smalltalker you eventually come down from your "OO rush" and realize that... hey, wait a minute! Polymorphism is not *tied* to class inheritance (unless you are trapped in some static type system). In fact, you realize that class inheritance in Smalltalk is "merely" a nice way of reducing the redundancy of code by creating dependencies between separate abstractions of code. This realization enables you to use inheritance in a more liberal fashion - which probably means you tend to use it *less*. And instead you tend to "add more objects" and use composition of objects more and more, relying on brittle deep hierarchies of inheritance less and less. SIDENOTE: A really cool example of how powerful object composition is: PetitParser by Lukas. For years we have been creating parsers by generating code from specifications and suddenly Lukas decides that hey, why not instead *compose* a parser from ...objects? It is so obvious in retrospect, but the result is a tremendously nicer and more powerful way of constructing parsers. You also conclude that while you *can* reuse behaviors and compose behaviors using inheritance you are also aware that inheritance creates a life cycle *dependency* between classes that you *may* or *may not* want to have. Class inheritance is a brittle relation. Thus, even if class A *can* inherit from B, you might decide not to - because you anticipate that the development lineage will diverge, or perhaps you have no control over A (library? other developer? bad code?), and you do not want that dependency. But the up side is that sometimes you *really* want that dependency, change superclass and bam - affect all subclasses. Another obvious benefit of inheritance is of course "documentation structure" that you and other developers can understand. ...well. Of course, the above was written sloppily and can of course be refined or totally shot down. Feel free to do both! :) regards, GÃ¶ran PS. Why oh why did Pharo lose the "double click on ? in the class browser to see inheritance textually"-mechanism? :)

Feb. 13, 2012