- Pharo-dev - lists.pharo.org

Re: [Pharo-project] instVarNames vs instVarNamed:

by Camillo Bruni

On 2012-09-24, at 20:24, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > What if we do it the other way? Add #variableNames to the instances :) in my opinion wrong :/, then you can start to replicate the whole class-side interface on the instance side... that's a never-ending circle. besides, that's yet another method on Object? :D > Nautilus new variableNames = Nautilus instVarNames. > > And them > > Nautilus new variableNames > ==> #('announcer' 'browsedEnvironment' 'browsingHistory' 'plugins' > 'selectedCategory' 'selectedClass' 'selectedGroup' 'selectedMethod' > 'selectedPackage' 'showCategories' 'showComment' 'showGroups' > 'showHierarchy' 'showInstance' 'showPackages' 'ui' 'uiClass') > > Nautilus new instVarNamed: 'announcer' > > ? > > Of course, that will happen/work at metaclass level too. > > Maybe rename #instVarNames to #myInstancesVariableNames? > > Guille

Sept. 24, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Guillermo Polito

What if we do it the other way? Add #variableNames to the instances :) Nautilus new variableNames = Nautilus instVarNames. And them Nautilus new variableNames ==> #('announcer' 'browsedEnvironment' 'browsingHistory' 'plugins' 'selectedCategory' 'selectedClass' 'selectedGroup' 'selectedMethod' 'selectedPackage' 'showCategories' 'showComment' 'showGroups' 'showHierarchy' 'showInstance' 'showPackages' 'ui' 'uiClass') Nautilus new instVarNamed: 'announcer' ? Of course, that will happen/work at metaclass level too. Maybe rename #instVarNames to #myInstancesVariableNames? Guille On Mon, Sep 24, 2012 at 8:18 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > On 2012-09-24, at 20:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > On Sep 24, 2012, at 6:51 PM, Camillo Bruni wrote: > >>>> Nautilus class instVarNames > >>> -> #('maxSize' 'cachedLastClasses' 'groups') > >>> > >>> ok we get the instance variables > >>> > >>> Nautilus class instVarNamed: 'groups' > >>> -> error > >>> > >>> For me that is wrong. I should not get an error, I should get the > actual > >>> variable. > >>> I mean, why #instVarNames workds but #instVarNamed: doesn't? That is > >>> inconsistent. > > > > to me mariano is right. if I can ask a class for a receiver a list of > stuff I should be able to > > send to the same receiver the value of the named elements. > > this distinction is confusing (Normally I know what is metaclass > programming) > > but with methods it's the very same, you get them no the class side, but > you > cannot do anything with them on the class. > > The problem is just that on a Class the instance side (of the Metaclass) > and the > class side collapse, so you have a double interface there. > > unless you have a strict and weird kind of separation of these two layers > like in Java, you will always have a double set of methods there.. >

Sept. 24, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Camillo Bruni

On 2012-09-24, at 20:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > On Sep 24, 2012, at 6:51 PM, Camillo Bruni wrote: >>>> Nautilus class instVarNames >>> -> #('maxSize' 'cachedLastClasses' 'groups') >>> >>> ok we get the instance variables >>> >>> Nautilus class instVarNamed: 'groups' >>> -> error >>> >>> For me that is wrong. I should not get an error, I should get the actual >>> variable. >>> I mean, why #instVarNames workds but #instVarNamed: doesn't? That is >>> inconsistent. > > to me mariano is right. if I can ask a class for a receiver a list of stuff I should be able to > send to the same receiver the value of the named elements. > this distinction is confusing (Normally I know what is metaclass programming) but with methods it's the very same, you get them no the class side, but you cannot do anything with them on the class. The problem is just that on a Class the instance side (of the Metaclass) and the class side collapse, so you have a double interface there. unless you have a strict and weird kind of separation of these two layers like in Java, you will always have a double set of methods there..

Sept. 24, 2012

Re: [Pharo-project] Webcam + barcode

by StÃ©phane Ducasse

Laurent Igor improved a lot the communication with Objective-C so we were thinking that it would be fun to see how to use the webcam but now igor is heavily hacking vm and all the team is moving to a new building. So we were packing and we will unpack everything. Stef On Sep 24, 2012, at 6:51 PM, laurent laffont wrote: > Thanks Torsten. Ideally I would like a Morph-based one. I've seen http://www.squeaksource.com/WebCamMorph.html but it doesn't seem to work > on Pharo OneClick > > Laurent > > On Mon, Sep 24, 2012 at 6:02 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > I remeber Seabreeze for Seaside had some > interface to webcam (using flash) and by using a > webservice to decode barcodes. > > You can see it in action in the second video at the bottom of > http://seabreeze.heeg.de/ > > A short description is here > http://seabreeze.heeg.de/files/SBWebsiteFiles/seaBreeze.pdf > > Maybe the barcode widget is available in the MIT licensed > open source distro (based on VisualWorks) > > Hope that helps! > > Bye > T. > >

Sept. 24, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by StÃ©phane Ducasse

On Sep 24, 2012, at 6:51 PM, Camillo Bruni wrote: >>> Nautilus class instVarNames >> -> #('maxSize' 'cachedLastClasses' 'groups') >> >> ok we get the instance variables >> >> Nautilus class instVarNamed: 'groups' >> -> error >> >> For me that is wrong. I should not get an error, I should get the actual >> variable. >> I mean, why #instVarNames workds but #instVarNamed: doesn't? That is >> inconsistent. to me mariano is right. if I can ask a class for a receiver a list of stuff I should be able to send to the same receiver the value of the named elements. this distinction is confusing (Normally I know what is metaclass programming)

Sept. 24, 2012

Re: [Pharo-project] Pharo and Namespaces

by StÃ©phane Ducasse

On Sep 24, 2012, at 6:04 PM, Torsten Bergmann wrote: >> Thanks for taking time at ESUG to listen and learn more about our namespace >proposal. I believe that we have cleared up some of the misconceptions >surrounding this complex topic. > > What was the outcome of the discussion? good question: I'm tired and my memory is weak. I will try to recall but it was clear and obvious that james got a point. in essence that we do not hardcode the resolution mechanism so that people can experiment. James? I'm sure that you will be more precise than me. Then camille should do a pass on his master and send it around. > Does the proposal fit or not? > What are the next steps? Send the master of camille around so that people can get a common understanding of the pros and cons. Do not expect namespace tomorrow, because we have plenty of other points to address first. And we lived without them during years so far so this is not namespace that we want but module. > > Thx > T. >

Sept. 24, 2012

Re: [Pharo-project] Webcam + barcode

by StÃ©phane Ducasse

I would love that ;) > Hi, > > I would like to scan a barcode with a webcam and get the ISBN of a book. Any help ? > > Cheers, > > Laurent

Sept. 24, 2012

Re: [Pharo-project] Webcam + barcode

by laurent laffont

Thanks Torsten. Ideally I would like a Morph-based one. I've seen http://www.squeaksource.com/WebCamMorph.html but it doesn't seem to work on Pharo OneClick Laurent On Mon, Sep 24, 2012 at 6:02 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > I remeber Seabreeze for Seaside had some > interface to webcam (using flash) and by using a > webservice to decode barcodes. > > You can see it in action in the second video at the bottom of > http://seabreeze.heeg.de/ > > A short description is here > http://seabreeze.heeg.de/files/SBWebsiteFiles/seaBreeze.pdf > > Maybe the barcode widget is available in the MIT licensed > open source distro (based on VisualWorks) > > Hope that helps! > > Bye > T. > >

Sept. 24, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Camillo Bruni

>> Nautilus class instVarNames > -> #('maxSize' 'cachedLastClasses' 'groups') > > ok we get the instance variables > > Nautilus class instVarNamed: 'groups' > -> error > > For me that is wrong. I should not get an error, I should get the actual > variable. > I mean, why #instVarNames workds but #instVarNamed: doesn't? That is > inconsistent. not at all... the class holds all the structural information. The class holds the description of the instances... The very same goes for methods: - You ask the class for the available methods - You invoke them on instances in parallel - You ask the class for the available variables - You ask the instance for the values of the variables So again: All structural information should be on the class side, all actual values have to be extracted from a living instance. I guess by having first-class layouts this discussion would be simplified, since slots/variables become first class instances. Plus adhering to strict naming conventions you will avoid this confusion Slots: the description (meta-object) of a Variable Variable: living instances with actual values on the objects furthermore you can then use the slot to read the variable from an instance :) and the circle is closed :) best cami

Sept. 24, 2012

Re: [Pharo-project] instVarNames vs instVarNamed:

by Igor Stasenko

On 24 September 2012 17:57, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Mon, Sep 24, 2012 at 12:14 PM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: >> >> I still don't see the problem.... >> >> everything is symmetrical, everything works... >> > > Nautilus class instVarNames > -> #('maxSize' 'cachedLastClasses' 'groups') > > ok we get the instance variables > > Nautilus class instVarNamed: 'groups' > -> error > > For me that is wrong. I should not get an error, I should get the actual > variable. > I mean, why #instVarNames workds but #instVarNamed: doesn't? That is > inconsistent. because you sending a message to wrong recepient. Should be: Nautilus instVarNamed: 'groups' > > Cheers, >> >> >> On 2012-09-24, at 11:18, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> > ...makes me envy the simplicity of SELF! >> > >> > Fernando >> > >> > On Mon, Sep 24, 2012 at 10:38 AM, Igor Stasenko <siguctua(a)gmail.com> >> > wrote: >> >> On 24 September 2012 08:53, StÃ©phane Ducasse >> >> <stephane.ducasse(a)inria.fr> wrote: >> >>> >> >>> On Sep 24, 2012, at 1:56 AM, Igor Stasenko wrote: >> >>> >> >>>> okay, i found what is wrong with first post (didn't read carefully). >> >>>> >> >>>> The instVarNames is a class-side protocol i.e. part of a class >> >>>> behavior, >> >>>> while instVarNamed: is an instance-side protocol i.e. "hackishly >> >>>> access to instance variable with given name" >> >>> >> >>> Yes this is exactly my point. >> >>> I think that there is a protocol missing for class to be consistent. >> >>> >> >> err, what is missing? class is an object, and using #instVarNamed: on >> >> them is perfectly fine. >> >> >> >> >> >>>> So, this is ok: >> >>>> Nautilus class instVarNames >> >>>> -> #('maxSize' 'cachedLastClasses' 'groups') >> >>>> >> >>>> And this is ok too: >> >>>> >> >>>> Nautilus instVarNamed: 'groups' >> >>>> worked >> >>>> >> >>>> because Nautilus is an instance of its metaclass. >> >>>> >> >>>> But this is wrong, since 'Nautilus class' is an instance of >> >>>> Metaclass, >> >>>> and metaclass doesn't have 'groups' variable. >> >>>> >> >>>> Nautilus class instVarNamed: 'groups' >> >>>> -> error >> >>>> >> >>>> >> >>>> -- >> >>>> Best regards, >> >>>> Igor Stasenko. >> >>>> >> >>> >> >>> >> >> >> >> >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko. >> >> >> > >> >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Best regards, Igor Stasenko.

Sept. 24, 2012