- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About traits

by Dale Henrichs

On 12/10/16 11:48 AM, stepharong wrote: > > Dale > > I missed your remark about traits. > I think that traits are nice because they act as a kind of static > macro expansion and really help to get multiple inheritance into > single one. > > Now ideally I would like to have > > (I hate so much this google nonUI) > > - state with traits with a nice initialization process. > - Now Pablo did a nice and simple implementation of Talents (dynamic > traits). I should have a look because if we could unify it and have > either a trait statically applied to a class (what we have now) and a > trait being applicable to an instance then it would be really good. > > > Now making the tools traits-aware is much more than just having traits > in the language. > - change > - loading > - editing > - overloading when we compile a method that comes from a trait we > should be able to say that it overrides..... > > What we did with the "unification" of traits and classes and the use > of traits inside the kernel is a mistake (in Squeak andreas if I > recall made Trait a subclass of classDescription > and this is not good either - even if he marketed it as a good idea) > and we will iterated to remove the use of traits from Class and friends. > Then ideally I would like to iterate over the > - reflective API (because we should be able to simply access the > "class" of a compiledMethod from where the traits is coming from or > where it is installed > - revisite the implementation because the clause composition. > > I think that the tools should not manipulate traits as classes because > traits are not classes. > Then doing this we will clarify that the traits and classes must not > be polymorphic because they are not. > Stef, Thanks for the clarification ... we are open to adding traits to GemStone and perhaps we should talk a little bit more about your ideas on a "better implementation" ... at this point GemStone 3.5 would be the target version and that would give us time for syncing up the implementation. Dale

Dec. 11, 2016

Re: [Pharo-dev] RBPattern matching dynamic array expressions

by John Brant

On 12/10/2016 02:37 AM, Nicolai Hess wrote: > Question : how should a pattern with three variables > (first/second/third) look like to match the expression > { (1@2) . Color red . 3} and assign the (sub)-expressions > 1@2 > Color red > 3 > to the three variables first/second/third ? The RB was written before the {} array syntax. It appears that are a few bugs in the pattern matching for the arrays. The first is that it needs to reset the isList variable of RBPatternVariableNode when it is part of a dynamic array. You can fix that by adding this to the end of RBPatternVariableNode>>parent: method: parent isDynamicArray ifTrue: [ self isStatement ifFalse: [ isList := false ] ] I think this will make the matching work like what you are expecting. If you want to match multiple statements, you need to add a ".", but if you just have "`@first", it will only match any expression node. While testing I noticed an error in the RBArrayNode>>match:inContext:. The method doesn't test the lengths of the nodes before sending the #with:do: message. If you try to match two arrays of different sizes, you get an error. This should be changed back to be: match: aNode inContext: aDictionary aNode class = self class ifFalse: [ ^ false ]. ^ self matchList: statements against: aNode statements inContext: aDictionary John Brant

Dec. 11, 2016

Re: [Pharo-dev] About traits

by Norbert Hartl

> Am 10.12.2016 um 20:48 schrieb stepharong <stepharong(a)free.fr>: > > > Dale > > I missed your remark about traits. > I think that traits are nice because they act as a kind of static macro expansion and really help to get multiple inheritance into single one. > > Now ideally I would like to have > (I hate so much this google nonUI) > > - state with traits with a nice initialization process. > - Now Pablo did a nice and simple implementation of Talents (dynamic traits). I should have a look because if we could unify it and have > either a trait statically applied to a class (what we have now) and a trait being applicable to an instance then it would be really good. Where is this Talents implementation? thanks, Norbert > > > Now making the tools traits-aware is much more than just having traits in the language. > - change > - loading > - editing > - overloading when we compile a method that comes from a trait we should be able to say that it overrides..... > > What we did with the "unification" of traits and classes and the use of traits inside the kernel is a mistake (in Squeak andreas if I recall made Trait a subclass of classDescription > and this is not good either - even if he marketed it as a good idea) and we will iterated to remove the use of traits from Class and friends. > Then ideally I would like to iterate over the > - reflective API (because we should be able to simply access the "class" of a compiledMethod from where the traits is coming from or where it is installed > - revisite the implementation because the clause composition. > > I think that the tools should not manipulate traits as classes because traits are not classes. > Then doing this we will clarify that the traits and classes must not be polymorphic because they are not. > > > > Stef >

Dec. 10, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60322 Home: https://github.com/pharo-project/pharo-core

Dec. 10, 2016

[pharo-project/pharo-core] 720e96: 60322

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 720e9665f2dce0565a05978e0f65b27143919b0b https://github.com/pharo-project/pharo-core/commit/720e9665f2dce0565a05978e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-12-10 (Sat, 10 Dec 2016) Changed paths: R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60321.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60322.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60321.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60322.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/MessageBrowser.class/instance/testing/buildHierarchyForMessages_.st Log Message: ----------- 60322 19447 VersionBrowser always shows single method https://pharo.fogbugz.com/f/cases/19447 http://files.pharo.org/image/60/60322.zip

Dec. 10, 2016

Re: [Pharo-dev] About traits

by stepharong

> Dale > > I missed your remark about traits.I think that traits are nice because > they act as a kind of static macro expansion and really help to get > multiple inheritance into single one. > Now ideally I would like to have (I hate so much this google nonUI) - state with traits with a nice initialization process. - Now Pablo did a nice and simple implementation of Talents (dynamic traits). I should have a look because if we could unify it and have either a trait statically applied to a class (what we have now) and a trait being applicable to an instance then it would be really good. Now making the tools traits-aware is much more than just having traits in the language. - change - loading - editing - overloading when we compile a method that comes from a trait we should be able to say that it overrides..... What we did with the "unification" of traits and classes and the use of traits inside the kernel is a mistake (in Squeak andreas if I recall made Trait a subclass of classDescription and this is not good either - even if he marketed it as a good idea) and we will iterated to remove the use of traits from Class and friends. Then ideally I would like to iterate over the - reflective API (because we should be able to simply access the "class" of a compiledMethod from where the traits is coming from or where it is installed - revisite the implementation because the clause composition. I think that the tools should not manipulate traits as classes because traits are not classes. Then doing this we will clarify that the traits and classes must not be polymorphic because they are not. Stef

Dec. 10, 2016

About traits

by Stephane Ducasse

Dale I missed your remark about traits. I think that traits are nice because they act as a kind of static macro expansion and really help to get multiple inheritance into single one. Now ideally I would like to have

Dec. 10, 2016

Re: [Pharo-dev] protocol pane "no messages" Re: [Pharo-users] setter method

by phil＠highoctane.be

Hi Ben, Yes and no. Because you can add a protocol right away without any method and end up in my layout. Pedantically yours, Phil On Sat, Dec 10, 2016 at 2:17 PM, Ben Coman <btc(a)openinworld.com> wrote: > Nope. I'll see your pedantic, and raise you... > > Clicking on "no messages" and adding a method you get... > --all-- > as yet unclassified. > > So "no protocols" goes away, but there are still no protocols. > > (pedantic poker, fun for all the family) > cheers -ben > > > On Sat, Dec 10, 2016 at 2:56 AM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > > To be pedantic it should be "no protocols" because as soon as you add > one, > > you get > > > > --all-- > > someaddedprotocol > > > > even if there is no method. > > > > Phil > > > > On Fri, Dec 9, 2016 at 7:21 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> > >> [Forwarded to pharo-dev for side discussion...] > >> > >> On Sat, Dec 10, 2016 at 2:15 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> > On Sat, Dec 10, 2016 at 1:39 AM, Kateryna Aloshkina > >> > <aloshkina(a)ucu.edu.ua> wrote: > >> >> Hi everybody! > >> >> > >> >> I've just joined the community:) and have a question > >> >> How to write the method count: such that, when invoked on an instance > >> >> of > >> >> Counter, instance variable is set to the argument given to the > message? > >> >> so that > >> >> Counter new count: 7 > >> >> would set the value of a new Counter instance to 7 > >> >> (It is a little exercise from > >> >> http://rmod-pharo-mooc.lille.inria.fr/MOOC/Exercises/Exo-Counter.pdf > ) > >> >> > >> >> > >> >> Best wishes, > >> >> Kateryna > >> > > >> > Welcome Kateryna, > >> > I hope you are having fun and Pharo changes the way you think about > >> > programming. > >> > > >> > Referring to Figure 1.2, assuming you've already created the class, > >> > first make sure you are on the instance-side rather than the > class-side > >> > of the class such that the class definition in the bottom (code) pane > >> > looks just like Figure 1.2. Click the <Class> button to toggle which > >> > side you look at. > >> > > >> > Now in the third (protocols) pane on "no messages" > >> > and you will get a method template in the code pane > >> > > >> > Change... messageSelectorAndArgumentNames > >> > to... count: > >> > > >> > then change.... statements > >> > to an assignment to the instance variable. > >> > and <Accept> the the code to save & compile the method. > >> > >> To be pedantic, shouldn't "no messages" actually be "no methods" > >> But maybe even better would be... "click for method template" ? > >> > >> cheers -ben > >> > > > >

Dec. 10, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60321 Home: https://github.com/pharo-project/pharo-core

Dec. 10, 2016

[pharo-project/pharo-core] 430d04: 60321

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 430d04886b116fa1cd45257f9a077b413c9179a5 https://github.com/pharo-project/pharo-core/commit/430d04886b116fa1cd45257f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-12-10 (Sat, 10 Dec 2016) Changed paths: A Kernel.package/MessageNotUnderstood.class/instance/accessing/smartDescription.st A Kernel.package/MessageNotUnderstood.class/instance/handling/debug.st A OpalCompiler-Core.package/OCShadowVariableWarning.class/instance/accessing/warningMessage.st A OpalCompiler-Core.package/OCShadowVariableWarning.class/instance/correcting/showWarningOnTranscript.st M OpalCompiler-Core.package/OCShadowVariableWarning.class/instance/correcting/variable_shadows_.st R OpalCompiler-Tests.package/MockTranscript.class/README.md R OpalCompiler-Tests.package/MockTranscript.class/definition.st R OpalCompiler-Tests.package/MockTranscript.class/instance/accessing/contents.st R OpalCompiler-Tests.package/MockTranscript.class/instance/initialization/initialize.st R OpalCompiler-Tests.package/MockTranscript.class/instance/streaming/cr.st R OpalCompiler-Tests.package/MockTranscript.class/instance/streaming/show_.st R OpalCompiler-Tests.package/MockTranscript.class/instance/updating/stepGlobal.st M OpalCompiler-Tests.package/OCCompilerTest.class/definition.st M OpalCompiler-Tests.package/OCCompilerTest.class/instance/running/setUp.st M OpalCompiler-Tests.package/OCCompilerTest.class/instance/running/tearDown.st R OpalCompiler-Tests.package/OCCompilerTest.class/instance/test shadowing/testNotInteractiveInBlockArgumentInstanceVariableShadowing.st R OpalCompiler-Tests.package/OCCompilerTest.class/instance/test shadowing/testNotInteractiveInBlockTempArgumentShadowing.st R OpalCompiler-Tests.package/OCCompilerTest.class/instance/test shadowing/testNotInteractiveInBlockTempInstanceVariableShadowing.st R OpalCompiler-Tests.package/OCCompilerTest.class/instance/test shadowing/testNotInteractiveInBlockTempShadowing.st R OpalCompiler-Tests.package/OCCompilerTest.class/instance/test shadowing/testNotInteractiveNoShadowing.st R OpalCompiler-Tests.package/OCCompilerTest.class/instance/test shadowing/testNotInteractiveShadowingOfTemp.st R OpalCompiler-Tests.package/OCCompilerTest.class/instance/test shadowing/testNotInteractiveSiblingBlocksInstanceVariableShadowing.st R OpalCompiler-Tests.package/OCCompilerTest.class/instance/test shadowing/testNotInteractiveSiblingBlocksTempShadowing.st M OpalCompiler-Tests.package/OCCompilerTest.class/instance/test shadowing/testSiblingBlocksTempShadowing.st R OpalCompiler-Tests.package/OCCompilerTest.class/instance/test shadowing/testTraitTempShadowing.st A OpalCompiler-Tests.package/OCCompilerTest.class/instance/test shadowing2/testNotInteractiveInBlockArgumentInstanceVariableShadowing.st A OpalCompiler-Tests.package/OCCompilerTest.class/instance/test shadowing2/testNotInteractiveInBlockTempArgumentShadowing.st A OpalCompiler-Tests.package/OCCompilerTest.class/instance/test shadowing2/testNotInteractiveInBlockTempInstanceVariableShadowing.st A OpalCompiler-Tests.package/OCCompilerTest.class/instance/test shadowing2/testNotInteractiveInBlockTempShadowing.st A OpalCompiler-Tests.package/OCCompilerTest.class/instance/test shadowing2/testNotInteractiveNoShadowing.st A OpalCompiler-Tests.package/OCCompilerTest.class/instance/test shadowing2/testNotInteractiveShadowingOfTemp.st A OpalCompiler-Tests.package/OCCompilerTest.class/instance/test shadowing2/testNotInteractiveSiblingBlocksInstanceVariableShadowing.st A OpalCompiler-Tests.package/OCCompilerTest.class/instance/test shadowing2/testNotInteractiveSiblingBlocksTempShadowing.st A OpalCompiler-Tests.package/OCCompilerTest.class/instance/test shadowing2/testTraitTempShadowing.st A OpalCompiler-Tests.package/OCCompilerTest.class/instance/utilities/tempTraitShadowingString.st A OpalCompiler-Tests.package/OCCompilerTest.class/instance/utilities/traitTempShadowingWarnings.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60320.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60321.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60320.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60321.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A SmartSuggestions.package/SugsMorphicTextAdapterContext.class/instance/refactoring/contentSelection.st A SmartSuggestions.package/SugsMorphicTextAdapterContext.class/instance/refactoring/selectionInterval.st Log Message: ----------- 60321 19437 Do not log shadowed variables to transcript by default https://pharo.fogbugz.com/f/cases/19437 19450 Suggestion menu not working on MessageBrowser https://pharo.fogbugz.com/f/cases/19450 19441 Better description for MessageNotUnderstood https://pharo.fogbugz.com/f/cases/19441 http://files.pharo.org/image/60/60321.zip

Dec. 10, 2016