- Pharo-users - lists.pharo.org

Re: [Pharo-users] Updating a project and NIL class variables

by Dimitris Chloupis

Thank you for the info but I think I did not make myself clear because you say "remain nil" Ok Imagine a class SomeClass and that class has a variable we will call SomeVariable, class variable that is , there is no class initialize method, now that class has a method that is eventually called , someMethod SomeVariable ifNil: [ SomeVariable := 'hello world'] so when I decide to update this class via metacello loading the latest version from github , SomeVariable will have the value 'hello world' My question is , will SomeVariable after I do the update revert back to nil or stay 'hello world' ? If your answer is no, and it stays 'hello world' then yes i need an initialize method and call it at update time. On Wed, Jan 20, 2016 at 2:54 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > They remain nil. > > That is why #initialize on the class side is needed. > > You can call that explicitly in a post load script, or rely on the class > loading mechanism that normally calls #initialize automatically when > loading a class. The warning is: this only happens when the *source* code > of the #initialize methods changes. So sometimes, you will have to touch > that method to force it. > > I hope that makes sense. > > See MCMethodDefinition>>#postloadOver: > > > On 20 Jan 2016, at 13:41, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > So my question is this , I have a class with nil variables that are lazy > initialised only when needed the first time and of course they keep their > values from there on. > > > > Lets say I get the latest update from github via metacello over an older > update that I already have inside the image , do those variables revert > back to nil values ? or do they keep their values as they are ? > > >

Jan. 20, 2016

Re: [Pharo-users] Updating a project and NIL class variables

by Ben Coman

On Wed, Jan 20, 2016 at 8:41 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > So my question is this , I have a class with nil variables that are lazy > initialised only when needed the first time and of course they keep their > values from there on. > > Lets say I get the latest update from github via metacello over an older > update that I already have inside the image , do those variables revert back > to nil values ? No. > or do they keep their values as they are ? Yes. Loading a package is only loading source code. Its no different than manually changing a method's source through the Nautilus system browser (instance & class variables keep their values throughout) except you get the whole lot in one go. cheers -ben

Jan. 20, 2016

Re: [Pharo-users] Updating a project and NIL class variables

by Hilaire

Is it instance or class variables ? In both cases, there are unchanged. If class variables, Sven explain how to reinitialize. Hilaire -- Dr. Geo http://drgeo.eu

Jan. 20, 2016

Re: [Pharo-users] [ANN] OSSubprocess v0.2.0 release

by Hilaire

https://github.com/marianopeck/OSSubprocess/ -- Dr. Geo http://drgeo.eu

Jan. 20, 2016

Re: [Pharo-users] Updating a project and NIL class variables

by Sven Van Caekenberghe

They remain nil. That is why #initialize on the class side is needed. You can call that explicitly in a post load script, or rely on the class loading mechanism that normally calls #initialize automatically when loading a class. The warning is: this only happens when the *source* code of the #initialize methods changes. So sometimes, you will have to touch that method to force it. I hope that makes sense. See MCMethodDefinition>>#postloadOver: > On 20 Jan 2016, at 13:41, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > So my question is this , I have a class with nil variables that are lazy initialised only when needed the first time and of course they keep their values from there on. > > Lets say I get the latest update from github via metacello over an older update that I already have inside the image , do those variables revert back to nil values ? or do they keep their values as they are ?

Jan. 20, 2016

Updating a project and NIL class variables

by Dimitris Chloupis

So my question is this , I have a class with nil variables that are lazy initialised only when needed the first time and of course they keep their values from there on. Lets say I get the latest update from github via metacello over an older update that I already have inside the image , do those variables revert back to nil values ? or do they keep their values as they are ?

Jan. 20, 2016

Re: [Pharo-users] Dynamic Typing > Static Typing? Â« games.greggman.com

by Dimitris Chloupis

I am a bit in the middle, I never cared or saw a practical benefit from static typing and neither I saw a practical benefit from using dynamic types. So its a matter that has little interest to me , but then I was never a language orientated person and I cared a lot more about IDEs and visual coding in general. However there is no doubt that dynamic types have won the war before the war started by the fact that in the history of coding at least the last 30 years I have been around we have witnessed 3 great migrations of coders 1) The migration from Assembly to C/C++ and other high level languages 2) The migration from C++ as the dominant force of coding to Java 3) The migration from static types languages to dynamic typed languages On the matter of python getting optional static typing I can say this and predict this, static type will never become anywhere as big for python as generic types are in static type languages and I say that because I have a good understanding of the python culture. In the end , does it really matter ? Languages are 99.9% personal preferences 0.1% practical needs. If you love coding with static types and you want to use them with your favorite dynamic language , go for it, code any way you want , if there is one thing that the coding field generally needs is to brake away from stereotypes , status quo and embrace innovation and alternative thinking. But I wont hold my breath for that :) On Wed, Jan 20, 2016 at 11:02 AM Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 20/01/2016 05:53, Martin BÃ¤hr a Ã©crit : > > Excerpts from Sven Van Caekenberghe's message of 2016-01-19 22:09:44 > +0100: > >>> http://games.greggman.com/game/dynamic-typing-static-typing/ < > http://games.greggman.com/game/dynamic-typing-static-typing/> > >> In a dynamically typed language you write (a lot) less code for a > shorter program that is easier and faster to write and debug, which gives > you more time to think about what you are doing, resulting in more reliable > programs. > >> > >> Static typing catches only a (very) small amount of typing errors, that > are just as easy to handle as dynamic typing exceptions, but they are a bit > faster. > > > > if that is the case, then why are people working on typescript, why are > both > > python and ruby getting optional types? > > I see two reasons > > - Static typing believers trying to retrofit types into successfull > dynamic languages, because it is impossible to write software without > static typing > > - Performance: for a compiler, having access to static types makes > compiling and performance optimisation a lot easier. This is my current > project (R compilation to heterogeneous targets) and I find that type > inference over R code is a hard (and interesting) subject. > > > i think this is a comparison of apples with oranges. > > even without typing languages like java, c and c++ are significantly > different > > from dynamic languages like python, ruby, smalltalk and others. > > > > adding typing to javascript, python and ruby means that we can have our > cake > > and eat it too. > > > so i'll wait for this study to be redone in the next decade, to compare > typed > > with untyped javascript, python and ruby. and only that will show us the > real > > truth. does adding types, with everything else being equal, really make a > > difference, or not? > > Will it? We already have meta-publication studies, and I must say that > even arguments like "static types reduces errors" are not even confirmed. > > I now wonder if type inference is even a good idea. I do think that > having explicit (static) typing has benefits; and having the ability to > remove those types declarations in specific places (APIs, for example) > seems to be a bad idea... Ocaml is a good example: large Ocaml systems > are very hard to extend, because types are often not written in the APIs > and extension points, and you rely on the IDE to scan the type inference > results to be able to understand how you are supposed to use a module... > I would really prefer to have incremental/optional typing to use types > at API entry points, to document and freeze the code. > > > btw: the guys at rubyrogues make an interesting argument why lack of > typing > > works better in smalltalk than it does in ruby: > > > http://devchat.cachefly.net/rubyrogues/transcript-155-rr-why-ruby-sucks-rub… > > read page 8 of that transcript. > > > > basically they are saying that because java and c/c++ are compiled they > can be > > analyzed statically and you can build great refactoring tools for them > because > > the tools can predict which methods are the same. > > and in difference to that smalltalk and lisp only know the code at > runtime and > > so they can't make those predictions. but they make up for that because > they > > are always running. there is no such thing as not runtime. you can > simply ask > > the system about its state, like find out which object in the whole > system > > would respond to a particular message. and in ruby you can't do either > of those. > > This is an interesting argument, except that if you had a correct model > of the code set, being able to run it doesn't seems as mandatory to > reason on it. Now, maybe Ruby need a Ring like implementation? > > > disclaimer: for the last 20 years, my main programming language has been > pike, > > a dynamic language like smalltalk, but with declarative typing. (it's > optional, > > in the sense that you can declare a type as "mixed" which can be > anything, so > > just like typescript, and how python and ruby will be once they have > optional > > types) > > > > greetings, martin. > > > Regards, > > Thierry > >

Jan. 20, 2016

Re: [Pharo-users] Dynamic Typing > Static Typing? Â« games.greggman.com

by Thierry Goubier

Le 20/01/2016 05:53, Martin BÃ¤hr a Ã©crit : > Excerpts from Sven Van Caekenberghe's message of 2016-01-19 22:09:44 +0100: >>> http://games.greggman.com/game/dynamic-typing-static-typing/ <http://games.greggman.com/game/dynamic-typing-static-typing/> >> In a dynamically typed language you write (a lot) less code for a shorter program that is easier and faster to write and debug, which gives you more time to think about what you are doing, resulting in more reliable programs. >> >> Static typing catches only a (very) small amount of typing errors, that are just as easy to handle as dynamic typing exceptions, but they are a bit faster. > > if that is the case, then why are people working on typescript, why are both > python and ruby getting optional types? I see two reasons - Static typing believers trying to retrofit types into successfull dynamic languages, because it is impossible to write software without static typing - Performance: for a compiler, having access to static types makes compiling and performance optimisation a lot easier. This is my current project (R compilation to heterogeneous targets) and I find that type inference over R code is a hard (and interesting) subject. > i think this is a comparison of apples with oranges. > even without typing languages like java, c and c++ are significantly different > from dynamic languages like python, ruby, smalltalk and others. > > adding typing to javascript, python and ruby means that we can have our cake > and eat it too. > so i'll wait for this study to be redone in the next decade, to compare typed > with untyped javascript, python and ruby. and only that will show us the real > truth. does adding types, with everything else being equal, really make a > difference, or not? Will it? We already have meta-publication studies, and I must say that even arguments like "static types reduces errors" are not even confirmed. I now wonder if type inference is even a good idea. I do think that having explicit (static) typing has benefits; and having the ability to remove those types declarations in specific places (APIs, for example) seems to be a bad idea... Ocaml is a good example: large Ocaml systems are very hard to extend, because types are often not written in the APIs and extension points, and you rely on the IDE to scan the type inference results to be able to understand how you are supposed to use a module... I would really prefer to have incremental/optional typing to use types at API entry points, to document and freeze the code. > btw: the guys at rubyrogues make an interesting argument why lack of typing > works better in smalltalk than it does in ruby: > http://devchat.cachefly.net/rubyrogues/transcript-155-rr-why-ruby-sucks-rub… > read page 8 of that transcript. > > basically they are saying that because java and c/c++ are compiled they can be > analyzed statically and you can build great refactoring tools for them because > the tools can predict which methods are the same. > and in difference to that smalltalk and lisp only know the code at runtime and > so they can't make those predictions. but they make up for that because they > are always running. there is no such thing as not runtime. you can simply ask > the system about its state, like find out which object in the whole system > would respond to a particular message. and in ruby you can't do either of those. This is an interesting argument, except that if you had a correct model of the code set, being able to run it doesn't seems as mandatory to reason on it. Now, maybe Ruby need a Ring like implementation? > disclaimer: for the last 20 years, my main programming language has been pike, > a dynamic language like smalltalk, but with declarative typing. (it's optional, > in the sense that you can declare a type as "mixed" which can be anything, so > just like typescript, and how python and ruby will be once they have optional > types) > > greetings, martin. > Regards, Thierry

Jan. 20, 2016

Re: [Pharo-users] Dynamic Typing > Static Typing? Â« games.greggman.com

by Sven Van Caekenberghe

> On 20 Jan 2016, at 08:07, stepharo <stepharo(a)free.fr> wrote: > > What is funny is that in general people do not believe us :). > So I decided that I do not want to talk with type freaks. Yes, that was something I forgot to add: it seems that both sides are really very different and opposed to each other. I also gave up this discussion. Personally, I am very much on the dynamic side, but I understand what typing offers. It is just that it does not offer enough: it fixes a small number of problems up front for an enormous cost in added code and loss of flexibility. What was also in the original article is the point that yes, refactoring is a bit easier, more correct and more powerful in a static typed language, but you need much more refactoring there because of all this extra coding to maintain the type constraints (again for little gain). Now, Common Lisp has, IMHO, the right approach to optional typing: not (so much) to catch errors, but specifically to instruct/help the compiler produce more efficient code. > Stef > > Le 19/1/16 22:09, Sven Van Caekenberghe a Ã©crit : >> Not that we didn't already know this or that we don't feel like this (else you wouldn't be here), but it is nice to see a concise description and some fact based reasoning around this subject: >> >>> http://games.greggman.com/game/dynamic-typing-static-typing/ <http://games.greggman.com/game/dynamic-typing-static-typing/> >> In summary: >> >> In a dynamically typed language you write (a lot) less code for a shorter program that is easier and faster to write and debug, which gives you more time to think about what you are doing, resulting in more reliable programs. >> >> Static typing catches only a (very) small amount of typing errors, that are just as easy to handle as dynamic typing exceptions, but they are a bit faster. >> >> Sven >> > >

Jan. 20, 2016

Re: [Pharo-users] Dynamic Typing > Static Typing? Â« games.greggman.com

by stepharo

What is funny is that in general people do not believe us :). So I decided that I do not want to talk with type freaks. Stef Le 19/1/16 22:09, Sven Van Caekenberghe a Ã©crit : > Not that we didn't already know this or that we don't feel like this (else you wouldn't be here), but it is nice to see a concise description and some fact based reasoning around this subject: > >> http://games.greggman.com/game/dynamic-typing-static-typing/ <http://games.greggman.com/game/dynamic-typing-static-typing/> > In summary: > > In a dynamically typed language you write (a lot) less code for a shorter program that is easier and faster to write and debug, which gives you more time to think about what you are doing, resulting in more reliable programs. > > Static typing catches only a (very) small amount of typing errors, that are just as easy to handle as dynamic typing exceptions, but they are a bit faster. > > Sven >

Jan. 20, 2016