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

Re: [Pharo-project] dependency injection

by Stephan Eggermont

Philippe wrote: > On 05/05/2012 10:04 AM, Milan Mimica wrote: >> What are you feelings about dependency injection? > > Oh oh, you brought up "the topic". We have about six different ways in > Seaside how we look up implementation classes. Anything from writing > them to a class variable to iterating over the subclasses and class > extensions. It would be really nice if we could replace them with one > approach. So that would be: afraid/angry, confused, despairing/hopeful? :)

May 8, 2012

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by Igor Stasenko

i agree with Stef.. about method metadata. imo array literals is more than enough to encode any data. yes, it may require a separate layer to convert it into instances of other classes ,like Dictionary, Author, Timestamp, PreviousVersionLink (+ add what you desire). So, you basically need to write a parser (or decoder) of array data. Which is imo much more simpler than parsing textual representation like JSON, STON and even smalltalk syntax. But lets stop fighting. Nothing is better a working solution, even if it not flawless. I would just use fuel to serialize any additional data associated with method. With some version information, so that i can make sure that i will be able to read it 10 years later. I don't care that humans will not be able to read it, because we have tools for that. End of story. -- Best regards, Igor Stasenko.

May 8, 2012

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by StÃ©phane Ducasse

> >> Finally and I still did not get a clear answer: why there is a need for dictionary syntax to store method meta data. > > (I still think we are all discussing different things, and I do understand your point, and I myself don't want to force STON on anybody). Yes this is not what I meant but I wanted to understand what people really want because so far this is still unclear to me. > But a quick question then, since I know you also know Lisp. Yes I still like its sexpressions style :) > Do you then see array literal syntax as s-expressions ? I do not know what you mean by that. The problem is that for objects it does not work (this is what we tried to do with selfEvaluating objects - it was to get as close as possible as true => true # (1 2 3) => #(1 2 3) {(10 @20) . (20@ 20)} => {(10 @20) . (20@ 20)} but {Person new} => anOrderedCollection (â¦.) > So that dictionaries/maps are like Lisp plists ? Yes kind of > > Dictionary new > at: #x put: 1; > at: #y put; 2; > yourself. > > would then be encoded like > > #( x 1 y 2 ) > yes or #((x 1) (y 2)) > ? > > Eventually doing a > > Dictionary newFromPairs:: #( x 1 y 2 ) > > ? > It would certainly work, with the know limitation that one has to know or understand the semantics upfront. Yessssssss :) And the plus that we do not have to have a new parser. the syntax for dictionary does just that. (ok it can be something big and important) but my question is what is the cost and the use case. Stef > > Sven

May 8, 2012

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by Sven Van Caekenberghe

StÃ©phane, On 08 May 2012, at 22:59, StÃ©phane Ducasse wrote: > Finally and I still did not get a clear answer: why there is a need for dictionary syntax to store method meta data. (I still think we are all discussing different things, and I do understand your point, and I myself don't want to force STON on anybody). But a quick question then, since I know you also know Lisp. Do you then see array literal syntax as s-expressions ? So that dictionaries/maps are like Lisp plists ? Dictionary new at: #x put: 1; at: #y put; 2; yourself. would then be encoded like #( x 1 y 2 ) ? Eventually doing a Dictionary newFromPairs:: #( x 1 y 2 ) ? It would certainly work, with the know limitation that one has to know or understand the semantics upfront. Sven

May 8, 2012

Re: [Pharo-project] Nautilus load problem

by StÃ©phane Ducasse

On May 8, 2012, at 10:38 PM, Benjamin wrote: > I will try to maintain Nautilus for 1.4 as long as I can, but we have all to keep in mind that now the main goal for Nautilus is to make it the default browser for 2.0. > > So obviously, I will focus more on the integration in 2.0. > But as long as we fix the system and make Nautilus work on it (as an example, the last PluggableListMorph changes) it means that Nautilus for 1.4 and Nautilus for 2.0 are different. Thanks benjmain. Did you try the latest version in 20? because e thought it looks strange with esteban BTW do you know if the font problems in the pane was fixed? Because usman got problems but in 1.4. I thought I fixed all the text morph to use the settings and that it was in 1.4 Stef > > But for more Nautilus related bugs, I will try to fix them in both :) > > > Let's hope I can manage to do that ^^ > > Ben > > > On May 8, 2012, at 7:11 PM, StÃ©phane Ducasse wrote: > >> >> On May 8, 2012, at 3:20 AM, Sean P. DeNigris wrote: >> >>> >>> Marcus Denker-4 wrote >>>> >>>> Nautilus... getting it ready will be double as hard if it has to run on >>>> both 1.4 and 2.0. >>>> >>> >>> Is Nautilus unsupported on 1.4? >> >> we should ask benjamin because he may fix the important problems. >> >> >>> There have been many suggestions to load it >>> in preference to the default browser in 1.4, so we should be clear whether >>> it will be expected to work. I guess then OB would be the only workable >>> option... but Nautilus is so cool - it's hard to go back, lol!! >>> >>> -- >>> View this message in context: http://forum.world.st/Nautilus-load-problem-tp4603363p4616242.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> > >

May 8, 2012

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by StÃ©phane Ducasse

>>> >> >> :) there is no security problem just that gemstone does not have a parser. Because parsing cannot be a security hole >> this is blind data interpretation that is a problem. This is why Github got problems and I imagine that the code was probably passed in JSON or similar format. > > Mmm, well, if you rely on full Compiler to parse literals, it is a security problem. But if you use the technique Igor showed to only parse array literals - then yes, that's safe, I agree. I forgot about his post. Parsing and compiling + execution are three different actions. Parsing: stream -> tokens* but you know it. >>> - There is no support for Associations as literals which means there is no good support in literals to express Dictionaries/key-value-pairs (like JSON has). Tirade has that in the form of literal Associations. I think we should add something in this area to Pharo/Smalltalk in general, but for more thoughts on that, please see article. >> >> Ok let me try to understand what I do not get. >> >> Do you mean that we cannot distinguish between >> #((a 13) 'a' 'b' 1 ) >> >> and >> #(a -> 13 'a' 'b' 1 ) >> >> why >> #(Dictionary (a 13) (b 15)) or #(Dictionary ((a 13) (b 15))) >> >> is not the same as >> #(Dictionary a-> 13 b ->15) >> >> Now the problem is that a -> 13 is not created at parse time. So I do not get why > > I presume you are describing various conventions/tricks to represent a Dictionary in a literal array, right? > > My point is that it would be nice if we actually had proper syntax for Associations (and or Dictionaries). OK I see. But what I want to say is that then this is not a literal array anymore. Literal means that you only need a parser and no execution to get the information. Parse time. Now I would like to know the use case for a dictionary syntax or association. May be you mean that you want to have the equivalent of { } but for dictionary, why not. Having a syntax for a syntax is not really exciting. Now I think that the key problem is dealing with reference between elements. for that STON can be better because why stopping at dictionary? But then the next question if we go down this road is why don't we add this syntax to smalltalk so that we can create literals objects like in Javascript. I mean without message send because this is exactly that no? What is the difference between Dictionary new add: #flop put: 33 ;yourself and {|% flop : 33 %|} or Person { name : 'stef' } then this is not really Smalltalk anymore and we cannot say that we only have messages and the parser and â¦. have to be changedâ¦. This is why I asked what is the use case. Finally and I still did not get a clear answer: why there is a need for dictionary syntax to store method meta data. Ok if you need a ***syntax*** then this is another requirement. Stef

May 8, 2012

Re: [Pharo-project] Nautilus load problem

by Benjamin

I will try to maintain Nautilus for 1.4 as long as I can, but we have all to keep in mind that now the main goal for Nautilus is to make it the default browser for 2.0. So obviously, I will focus more on the integration in 2.0. But as long as we fix the system and make Nautilus work on it (as an example, the last PluggableListMorph changes) it means that Nautilus for 1.4 and Nautilus for 2.0 are different. But for more Nautilus related bugs, I will try to fix them in both :) Let's hope I can manage to do that ^^ Ben On May 8, 2012, at 7:11 PM, StÃ©phane Ducasse wrote: > > On May 8, 2012, at 3:20 AM, Sean P. DeNigris wrote: > >> >> Marcus Denker-4 wrote >>> >>> Nautilus... getting it ready will be double as hard if it has to run on >>> both 1.4 and 2.0. >>> >> >> Is Nautilus unsupported on 1.4? > > we should ask benjamin because he may fix the important problems. > > >> There have been many suggestions to load it >> in preference to the default browser in 1.4, so we should be clear whether >> it will be expected to work. I guess then OB would be the only workable >> option... but Nautilus is so cool - it's hard to go back, lol!! >> >> -- >> View this message in context: http://forum.world.st/Nautilus-load-problem-tp4603363p4616242.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

May 8, 2012

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by GÃ¶ran Krampe

On 05/08/2012 09:01 PM, StÃ©phane Ducasse wrote: > > On May 8, 2012, at 8:33 PM, GÃ¶ran Krampe wrote: > >> On 05/08/2012 07:46 PM, StÃ©phane Ducasse wrote: >>> for me I can understand that people want a format to exchange objects and that they want to use STON but >>> I do not understand why we need that to store metadata when a simple array works. Probably we love to >>> load our boat with extra readers and writers. >> >> No, it was just a "trigger" for this discussion/comparison. >> >> BUT... I would like you to at least read the parts in my article which is about improving the literal support we have in Smalltalk/Pharo. The main "problem" with literals that I can see (compared to Tirade) are: >> >> - There is no restricted parser for them (as Tirade is), you need to use Compiler and that is a HUGE security problem. But of course, you are fixing that, right? :) > > :) there is no security problem just that gemstone does not have a parser. Because parsing cannot be a security hole > this is blind data interpretation that is a problem. This is why Github got problems and I imagine that the code was probably passed in JSON or similar format. Mmm, well, if you rely on full Compiler to parse literals, it is a security problem. But if you use the technique Igor showed to only parse array literals - then yes, that's safe, I agree. I forgot about his post. >> - There is no support for Associations as literals which means there is no good support in literals to express Dictionaries/key-value-pairs (like JSON has). Tirade has that in the form of literal Associations. I think we should add something in this area to Pharo/Smalltalk in general, but for more thoughts on that, please see article. > > Ok let me try to understand what I do not get. > > Do you mean that we cannot distinguish between > #((a 13) 'a' 'b' 1 ) > > and > #(a -> 13 'a' 'b' 1 ) > > why > #(Dictionary (a 13) (b 15)) or #(Dictionary ((a 13) (b 15))) > > is not the same as > #(Dictionary a-> 13 b ->15) > > Now the problem is that a -> 13 is not created at parse time. So I do not get why I presume you are describing various conventions/tricks to represent a Dictionary in a literal array, right? My point is that it would be nice if we actually had proper syntax for Associations (and or Dictionaries). regards, GÃ¶ran

May 8, 2012

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by Dale Henrichs

Stef, To me your argument is equivalent to saying "we've got nails why do we need screws"...Where ever you use a screw you should be able to use a nail right? But screws have slightly different characteristics than nails and when those characteristics are called for you use a screw instead of a nail... right? STON, JSON, Tirade and literal arrays all perform the same basic function, but each have slightly different characteristics that make one better for some tasks and another better for other tasks ... right? Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Tuesday, May 8, 2012 12:03:18 PM | Subject: Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation) | | | On May 8, 2012, at 8:32 PM, Dale Henrichs wrote: | | > :):):) for the correct definition of "works" I agree :):):) | | sorry but I did not get it funny at all. | But if you laugh even better. So far I do not understand but I'm | probably an idiot understand | why we need dictionary syntax. But again this should be that I'm | totally dull on that topics. | So I will not read mails about this topic anymore. | Too bad may be people could have gained from my idiot views. | | Stef | | > | > Dale | > | > ----- Original Message ----- | > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | > | To: Pharo-project(a)lists.gforge.inria.fr | > | Sent: Tuesday, May 8, 2012 10:46:08 AM | > | Subject: Re: [Pharo-project] A comparative article (was Re: | > | [squeak-dev] [ANN] STON - Smalltalk Object Notation) | > | | > | for me I can understand that people want a format to exchange | > | objects | > | and that they want to use STON but | > | I do not understand why we need that to store metadata when a | > | simple | > | array works. Probably we love to | > | load our boat with extra readers and writers. | > | | > | Stef | > | | > | | > | On May 8, 2012, at 2:05 PM, Sven Van Caekenberghe wrote: | > | | > | > (The paper was indeed just updated a couple of days ago). | > | > | > | > On 08 May 2012, at 13:29, GÃ¶ran Krampe wrote: | > | > | > | >> - In general I believe in 99% of the cases the parsing system | > | >> has | > | >> to know what it is parsing, how the JSON looks and how it | > | >> should | > | >> be mapped onto objects. Making the JSON parser itsy bitsy | > | >> smarter | > | >> with type annotations doesn't help me there, I still need to | > | >> know | > | >> that I want to instantiate a PDFPage and put this Rectangle | > | >> into | > | >> it - but oh, perhaps not as a Rectangle, but perhaps as two | > | >> points sent into a class side instantiation message or | > | >> something. | > | >> | > | >> My point being that the type annotations doesn't "buy me" | > | >> enough. | > | > | > | > (Just for the sake of the argument, I don't want to convince | > | > you) | > | > | > | > STON *does* buy you that: as long as we are talking about | > | > 'domain | > | > level objects' (a vague notion I agree) your Smalltalk object | > | > will | > | > serialize without any extra effort (see the ZnResponse example | > | > in | > | > the paper). You can customize some objects if you want to | > | > (mostly | > | > for readability, sometimes to fix some issue). | > | > | > | > Object implements #toSton: and #fromSton: by iterating over the | > | > instances variables. | > | > | > | > The issues are: Blocks, Classes and the fact that ephemeral | > | > instances are always serialized. | > | > | > | > Sven | > | > | > | > | > | | > | | > | | > | | |

May 8, 2012

Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation)

by StÃ©phane Ducasse

On May 8, 2012, at 8:32 PM, Dale Henrichs wrote: > :):):) for the correct definition of "works" I agree :):):) sorry but I did not get it funny at all. But if you laugh even better. So far I do not understand but I'm probably an idiot understand why we need dictionary syntax. But again this should be that I'm totally dull on that topics. So I will not read mails about this topic anymore. Too bad may be people could have gained from my idiot views. Stef > > Dale > > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Tuesday, May 8, 2012 10:46:08 AM > | Subject: Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation) > | > | for me I can understand that people want a format to exchange objects > | and that they want to use STON but > | I do not understand why we need that to store metadata when a simple > | array works. Probably we love to > | load our boat with extra readers and writers. > | > | Stef > | > | > | On May 8, 2012, at 2:05 PM, Sven Van Caekenberghe wrote: > | > | > (The paper was indeed just updated a couple of days ago). > | > > | > On 08 May 2012, at 13:29, GÃ¶ran Krampe wrote: > | > > | >> - In general I believe in 99% of the cases the parsing system has > | >> to know what it is parsing, how the JSON looks and how it should > | >> be mapped onto objects. Making the JSON parser itsy bitsy smarter > | >> with type annotations doesn't help me there, I still need to know > | >> that I want to instantiate a PDFPage and put this Rectangle into > | >> it - but oh, perhaps not as a Rectangle, but perhaps as two > | >> points sent into a class side instantiation message or something. > | >> > | >> My point being that the type annotations doesn't "buy me" enough. > | > > | > (Just for the sake of the argument, I don't want to convince you) > | > > | > STON *does* buy you that: as long as we are talking about 'domain > | > level objects' (a vague notion I agree) your Smalltalk object will > | > serialize without any extra effort (see the ZnResponse example in > | > the paper). You can customize some objects if you want to (mostly > | > for readability, sometimes to fix some issue). > | > > | > Object implements #toSton: and #fromSton: by iterating over the > | > instances variables. > | > > | > The issues are: Blocks, Classes and the fact that ephemeral > | > instances are always serialized. > | > > | > Sven > | > > | > > | > | > | >

May 8, 2012