- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Unified property API for code.

by Tudor Girba

Hi, I also vote for the xyzAt:put: pattern, even though propertyAt: sounds less English than propertyNamed:. Cheers, Doru On Sat, Aug 15, 2015 at 11:03 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 15 Aug 2015, at 10:46, stepharo <stepharo(a)free.fr> wrote: > > > > Excellent initiative. > > > > In Moose we get > > > > propertyNamed: propertyName > > propertyNamed: name ifAbsentPut: value > > propertyNamed: propertyName ifNil: aBlock > > propertyNamed: name put: value > > > Ah, no, this is version (5). I guess #propertyValueNamed: would be number > 6). > > > So which one do we take? > > I would use the one that is most close to what we do with #at: > > The thing is that all these additional words have no meaning. (named, > value). Thatâs why everyone uses another one. > > I think we should have just and API following #at: and #at:put: with > âpropertyâ attached to it. > Simple, learnable, easy. > > which is (2). > > propertyAt: > > > Stef > > > > Le 15/8/15 10:24, Marcus Denker a Ã©crit : > >> Hi, > >> > >> I am now adding a property API to Global/Class Variables and Instance > Variables (aka Slots). > >> > >> When looking at the other property APIs, we have 4 different > conventions: > >> > >> 1) CompiledMethod and Behavior: > >> > >> propertyValueAt: > >> > >> 2) RB AST Nodes: > >> propertyAt: > >> > >> 3) Ring: > >> annotationNamed: > >> > >> and (4) Morphic uses: > >> valueOfProperty: > >> > >> > >> I would like to unify 1-3 as this is all the same use case: attaching > meta data to the > >> structural model. > >> > >> I propose to unify the API to the same as the RB AST: just > #propertyAt:. Morphic we should > >> not touch... > >> > >> Marcus > >> > > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 15, 2015

Re: [Pharo-dev] Unified property API for code.

by Marcus Denker

> On 15 Aug 2015, at 10:46, stepharo <stepharo(a)free.fr> wrote: > > Excellent initiative. > > In Moose we get > > propertyNamed: propertyName > propertyNamed: name ifAbsentPut: value > propertyNamed: propertyName ifNil: aBlock > propertyNamed: name put: value > Ah, no, this is version (5). I guess #propertyValueNamed: would be number 6). > So which one do we take? I would use the one that is most close to what we do with #at: The thing is that all these additional words have no meaning. (named, value). Thatâs why everyone uses another one. I think we should have just and API following #at: and #at:put: with âpropertyâ attached to it. Simple, learnable, easy. which is (2). propertyAt: > Stef > > Le 15/8/15 10:24, Marcus Denker a Ã©crit : >> Hi, >> >> I am now adding a property API to Global/Class Variables and Instance Variables (aka Slots). >> >> When looking at the other property APIs, we have 4 different conventions: >> >> 1) CompiledMethod and Behavior: >> >> propertyValueAt: >> >> 2) RB AST Nodes: >> propertyAt: >> >> 3) Ring: >> annotationNamed: >> >> and (4) Morphic uses: >> valueOfProperty: >> >> >> I would like to unify 1-3 as this is all the same use case: attaching meta data to the >> structural model. >> >> I propose to unify the API to the same as the RB AST: just #propertyAt:. Morphic we should >> not touch... >> >> Marcus >> > >

Aug. 15, 2015

Re: [Pharo-dev] we are running dependencies breaking sprints....

by Tudor Girba

This is exciting. Thanks a lot for this effort! Doru On Sat, Aug 15, 2015 at 10:50 AM, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > just to let you know that we run a dependencies breaking sprint yesterday > and it was great. > We will redo one or two. > Our goal is to minimise the dependencies of adding Monticello to the pharo > bootstrap. > What I can tell you is that having a bootstrap is bringing an > ***AMAZING*** level of cleaner design. > I suspected it. But when we see the real cases this is obvious and really > important. > I will really open a complete new world for Pharo in terms of modularity > (of course it will take time > but this is really really cool). > > Stef > > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 15, 2015

we are running dependencies breaking sprints....

by stepharo

Hi guys just to let you know that we run a dependencies breaking sprint yesterday and it was great. We will redo one or two. Our goal is to minimise the dependencies of adding Monticello to the pharo bootstrap. What I can tell you is that having a bootstrap is bringing an ***AMAZING*** level of cleaner design. I suspected it. But when we see the real cases this is obvious and really important. I will really open a complete new world for Pharo in terms of modularity (of course it will take time but this is really really cool). Stef

Aug. 15, 2015

Re: [Pharo-dev] Unified property API for code.

by stepharo

Excellent initiative. In Moose we get propertyNamed: propertyName propertyNamed: name ifAbsentPut: value propertyNamed: propertyName ifNil: aBlock propertyNamed: name put: value So which one do we take? Stef Le 15/8/15 10:24, Marcus Denker a Ã©crit : > Hi, > > I am now adding a property API to Global/Class Variables and Instance Variables (aka Slots). > > When looking at the other property APIs, we have 4 different conventions: > > 1) CompiledMethod and Behavior: > > propertyValueAt: > > 2) RB AST Nodes: > propertyAt: > > 3) Ring: > annotationNamed: > > and (4) Morphic uses: > valueOfProperty: > > > I would like to unify 1-3 as this is all the same use case: attaching meta data to the > structural model. > > I propose to unify the API to the same as the RB AST: just #propertyAt:. Morphic we should > not touch... > > Marcus >

Aug. 15, 2015

Unified property API for code.

by Marcus Denker

Hi, I am now adding a property API to Global/Class Variables and Instance Variables (aka Slots). When looking at the other property APIs, we have 4 different conventions: 1) CompiledMethod and Behavior: propertyValueAt: 2) RB AST Nodes: propertyAt: 3) Ring: annotationNamed: and (4) Morphic uses: valueOfProperty: I would like to unify 1-3 as this is all the same use case: attaching meta data to the structural model. I propose to unify the API to the same as the RB AST: just #propertyAt:. Morphic we should not touch... Marcus

Aug. 15, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 15, 2015

[pharo-project/pharo-core] 3192f5: 50231

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 3192f5a49da5913bb016f82732c4275ec82b8a02 https://github.com/pharo-project/pharo-core/commit/3192f5a49da5913bb016f827… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-15 (Sat, 15 Aug 2015) Changed paths: A NECompletion.package/NECPreferences.class/class/class initialization/initialize.st A NECompletion.package/NECPreferences.class/class/defaults/defaultPopupDelay.st A NECompletion.package/NECPreferences.class/class/defaults/defaultPopupShortcut.st A NECompletion.package/NECPreferences.class/class/defaults/defaultPopupShowAutomatic.st A NECompletion.package/NECPreferences.class/class/defaults/defaultSpaceAfterCompletion.st R NECompletion.package/NECPreferences.class/class/defaults/initialize.st R NECompletion.package/NECPreferences.class/class/settings/defaultPopupDelay.st R NECompletion.package/NECPreferences.class/class/settings/defaultPopupShortcut.st R NECompletion.package/NECPreferences.class/class/settings/defaultPopupShowAutomatic.st R NECompletion.package/NECPreferences.class/class/settings/defaultSpaceAfterCompletion.st A Reflectivity-Tests.package/GlobalForTesting.class/README.md A Reflectivity-Tests.package/GlobalForTesting.class/definition.st A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - variables/testSetLinkOnGlobalVariable.st A Reflectivity-Tests.package/ReflectiveMethodTest.class/instance/tests - variables/testSetLinkOnGlobalVariableAndUninstall.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - after/testAfterVariable.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - before/testBeforeVariable.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testReplaceVariableReadGlobal.st M Reflectivity-Tests.package/ReflectivityExamples.class/instance/examples/exampleGlobalRead.st M Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyGlobalName.st M Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyGlobalValue.st M Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - variables/testReifyGlobalVariable.st M Reflectivity.package/LinkWrapperGlobal.class/instance/installing/uninstall.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50230.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50231.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50230.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50231.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50231 16208 System-Support should have a System-Support-Tests https://pharo.fogbugz.com/f/cases/16208 16179 Reflectivity: Set Links on Globals https://pharo.fogbugz.com/f/cases/16179 16216 Default values in NECPreferences are not initilized right https://pharo.fogbugz.com/f/cases/16216 http://files.pharo.org/image/50/50231.zip

Aug. 15, 2015

Re: [Pharo-dev] Getting some tag in an HTML file

by monty

Doru's suggestion of PP + islands is good and makes building complex parsers easy, but his toy example gives wrong results: <script> function end() { document.writeln('</script>'); } function start() { document.writeln('<script>'); } </script> or: <script> alert('hello'); // <script> alert('world') </script> or:  better to use one of the proper HTML parsers, at least if you need more correctness.

Aug. 15, 2015

Re: [Pharo-dev] Getting some tag in an HTML file

by monty

You need to install XMLParserHTML from the Config(Pharo4) or Catalog(Pharo5) browser. Disabling validation like Vincent said isn't enough because non-validating xml parsers still expect documents to be wellformed (which includes proper nesting and closing of tags). Validation is just a set of additional constraints like checking against a DTD if present. XMLParserHTML will load SAX and DOM parsers that accept messy HTML, but they were kind of an afterthought so I don't promote them to people already using something else (like Soup or Todd's parser) that are happy with it. Their advantage is speed (the fastest HTML parsers for Pharo or Squeak by far) and integration with XMLParser and related libs.

Aug. 15, 2015