Le 23/2/15 15:53, Sven Van Caekenberghe a écrit :

Cool, we're back in business ;-)

yes but why having String>>asPackage is better? Stef

I know! Now I wanted to say that we are binding everything together. We are just making the job of people like Pavel and Guille more difficult. We should not expect that they will continue to produce a modular core if we do not pay attention like that. At least I would be them, I would stop. If we decide to bind package that deep into the system (because String is deep) then may be we should have package inside Class definition themselves. Stef Le 23/2/15 15:53, Sven Van Caekenberghe a écrit :

...

...

Cool, we're back in business ;-) yes but why having String>>asPackage is better?

Stef I was commenting on the CI/Integration process, not this particular issue.

It is symmetrical to String>>asClass which proves rather elegant for scripting class lookup.

Why is it not good? Because you are binding RPackage (which is for now a layer on top of class) directly inside the kernel and this should not be done like that. May be you defined it as a class extension (I hope) I could not see the code. We should stop extending core classes. It makes the system more complex to maintain and decompose.

String should not contain all the asXXXX methods from earth. Why we do not have asMethod, asPoint, asPlayer, asSound ? Stef

Le 23/2/15 15:53, Sven Van Caekenberghe a écrit :

Cool, we're back in business ;-)

yes but why having String>>asPackage is better?

Stef

-- www.tudorgirba.com <http://www.tudorgirba.com>

"Every thing has its own flow"

Just my 2 cents: I find this really useful and have already implemented this extension in a couple of my packages, as writing: RuleChecker check: (RPackageOrganizer default packageNamed: ‘Kernel’) is much worse than: RuleChecker check: ‘Kernel’ asPackage Uko

On 23 Feb 2015, at 23:27, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi,

Indeed, having all "asXYZ from the Earth" would not be desirable to have in the Kernel, but: - asPackage is packaged in *RPackage-SystemIntegration, so it's not in the Kernel - I think extending String is a cheap and rather elegant way to ease common access patterns, and in this case RPackage is a common thing to look at.

So, from this perspective, I think it is good to have asPackage.

If my main system would be something about Players, and I would need ways to script that be sure I would have an asPlayer in my image (not in Pharo though :)).

I would have actually preferred to put this in Symbol, but I saw that asClass is in String and I implemented it in the same way.

Cheers, Doru

On Mon, Feb 23, 2015 at 11:16 PM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:

...

It is symmetrical to String>>asClass which proves rather elegant for scripting class lookup.

Why is it not good? Because you are binding RPackage (which is for now a layer on top of class) directly inside the kernel and this should not be done like that. May be you defined it as a class extension (I hope) I could not see the code. We should stop extending core classes. It makes the system more complex to maintain and decompose.

String should not contain all the asXXXX methods from earth. Why we do not have asMethod, asPoint, asPlayer, asSound ?

Stef

...

Le 23/2/15 15:53, Sven Van Caekenberghe a écrit : Cool, we're back in business ;-)

yes but why having String>>asPackage is better?

Stef

-- www.tudorgirba.com <http://www.tudorgirba.com/>

"Every thing has its own flow"

-- www.tudorgirba.com <http://www.tudorgirba.com/>

"Every thing has its own flow"

Interesting idea. We should have a guy trying. I would be curious to see what is happening in the context of Conch (the module system of camille). He should present it to us too. But we would need somebody to work on the tools. Now for me what I would prefer is to have a kernel in which class have a direct pointer to their packages like for their super/subclasses. Stef Le 24/2/15 08:01, Marcus Denker a écrit :

...

On 24 Feb 2015, at 07:49, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:

Just my 2 cents:

I find this really useful and have already implemented this extension in a couple of my packages, as writing:

RuleChecker check: (RPackageOrganizer default packageNamed: ‘Kernel’)

is much worse than:

RuleChecker check: ‘Kernel’ asPackage

Sometimes I wonder if Packages should not be part of the Smalltalk globals namespace…

e.g. packages could have a nice reflective API:

MyPackage unload.

and even an API for using… e.g. a Compiler has a very tiny surface API:

OpalCompiler compile: ‘….’

(but I do not really like nested classes, which is what people will now suggest…)

Marcus

That’s close to one of the first thing I tried when I started with Pharo, and I liked it (you didn’t back then ;) ). ;)

Packages were globals (so no dashes in their name unfortunately) and answered #import: #import:as: #load #unload #@… Each package was defining an environment for its classes and this environment had a ThisEnvironment binding pointing to itself. You could change imports with statements like: ThisEnvironment import: SomePackage @ #SomeClass as: #LocalName.

The only difference with what Marcus suggests is that packages didn’t have business-level behavior. If you want that, nested classes sound like a good solution since in that context both packages and classes define behavior and are instanciable. So it worth unifying both concepts. I tried that also, but first it’s much more difficult to implement cleanly (I remember that I had to rely on many little hacks to make it work) and then it's a huge paradigm shift we can’t afford (basically transforming Pharo into Newspeak). If we were writing a new language I would say yes, go for nested classes, but integrating into them into Pharo, no. And in the end, not many packages offer a stand-alone service like Compiler does. So instead, having one class in a package that acts as a facade is good enough to me.

agreed with you

...

I would be curious to see what is happening in the context of Conch (the module system of camille). He should present it to us too. Conch is about local extension methods, not about global variables. Dealing with globals is much simpler, partly because the problem itself is simpler, partly because the infrastructure is already there: classes answer to #environment and that’s what is used during compilation instead of 'Smalltalk globals'.

...

But we would need somebody to work on the tools. Yes, that’s the difficult part for any language extension. And code migration...

...

Now for me what I would prefer is to have a kernel in which class have a direct pointer to their packages like for their super/subclasses. Classes already have an #environment and it does the job. Of course, we could rename it to #package if we all agree that to one package corresponds one environment.

Camille

...

Stef

Le 24/2/15 08:01, Marcus Denker a écrit :

...

...

On 24 Feb 2015, at 07:49, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:

Just my 2 cents:

I find this really useful and have already implemented this extension in a couple of my packages, as writing:

RuleChecker check: (RPackageOrganizer default packageNamed: ‘Kernel’)

is much worse than:

RuleChecker check: ‘Kernel’ asPackage

Sometimes I wonder if Packages should not be part of the Smalltalk globals namespace…

e.g. packages could have a nice reflective API:

MyPackage unload.

and even an API for using… e.g. a Compiler has a very tiny surface API:

OpalCompiler compile: ‘….’

(but I do not really like nested classes, which is what people will now suggest…)

Marcus

Doru and Yuriy String is not a good API for reflective operations. This is what you are doing with asPackage. When I want to access to a class I do Class or Smalltalk globals classNamed: 'Point' a compile method Point>>#x and not 'Point?x' asCompiledMethod I would prefer to have Package named: 'jkljk' than the string behavior. and what if I want to reflect on code that is remote? So I maintain that we are polluting String with reflective operations that it should not have. Stef

On 24 Feb 2015, at 09:33, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:

But for configuration everyone anyway uses

‘CoufigurationOf…’ asClass load

I wasn’t aware that #asClass existed… ;)

no?

Uko

...

On 24 Feb 2015, at 08:57, stepharo <stepharo@free.fr> wrote:

Doru and Yuriy

String is not a good API for reflective operations. This is what you are doing with asPackage. When I want to access to a class I do Class or Smalltalk globals classNamed: 'Point' a compile method Point>>#x and not 'Point?x' asCompiledMethod I would prefer to have Package named: 'jkljk' than the string behavior.

and what if I want to reflect on code that is remote?

So I maintain that we are polluting String with reflective operations that it should not have.

Stef

2015-02-24 9:48 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:

...

On 24 Feb 2015, at 09:47, Max Leske <maxleske@gmail.com> wrote:

...

On 24 Feb 2015, at 09:33, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:

But for configuration everyone anyway uses

‘CoufigurationOf…’ asClass load

I wasn’t aware that #asClass existed… ;)

You are a Noob, Max ;-)

Maybe 'Foo' as: Class -> String>>as: aBehavior ^aBehavior fromString: self -> ^Class fromString: 'Foo' or something like that?

...

...

no?

Uko

...

On 24 Feb 2015, at 08:57, stepharo <stepharo@free.fr> wrote:

Doru and Yuriy

String is not a good API for reflective operations. This is what you

are doing with asPackage.

...

...

When I want to access to a class I do Class or Smalltalk globals classNamed: 'Point' a compile method Point>>#x and not 'Point?x' asCompiledMethod I would prefer to have Package named: 'jkljk' than the string behavior.

and what if I want to reflect on code that is remote?

So I maintain that we are polluting String with reflective operations that it should not have.

Stef

On 24 Feb 2015, at 10:06, Marcus Denker <marcus.denker@inria.fr> wrote:

...

On 24 Feb 2015, at 09:58, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote:

2015-02-24 9:48 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>>:

...

On 24 Feb 2015, at 09:47, Max Leske <maxleske@gmail.com <mailto:maxleske@gmail.com>> wrote:

...

On 24 Feb 2015, at 09:33, Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote:

But for configuration everyone anyway uses

‘CoufigurationOf…’ asClass load

I wasn’t aware that #asClass existed… ;)

You are a Noob, Max ;-)

Maybe

'Foo' as: Class -> String>>as: aBehavior ^aBehavior fromString: self -> ^Class fromString: 'Foo'

or something like that?

I wonder why we do not just late-bind global access.

Yes why not. The question is: late-bind onto whom? Since bindings can be changed without recompilation, I’m not sure that late-bound global have a lot of added value. Camille

Marcus

On 24 Feb 2015, at 13:22, Marcus Denker <marcus.denker@inria.fr> wrote:

...

Yes why not. The question is: late-bind onto whom? Since bindings can be changed without recompilation, I’m not sure that late-bound global have a lot of added value.

In the sense that I can write

MyNonExistingClass new.

and get a runtime error.

Yes true.

Marcus

stepharo wrote

...

I wonder why we do not just late-bind global access. ...and to me this is better than poor string.

Yes!!! This would be really nice. It's one of those gotcha places where the system isn't quite turtles all the way down, like optimized methods that you can't override. It would be great for testing to be able to inject for example a stub class for the real class, but right now that's pretty hard and error prone bc IIRC you have to go down into he literal array of the compiled method. ----- Cheers, Sean -- View this message in context: http://forum.world.st/pharo-project-pharo-core-3fabea-40497-tp4806951p480729... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Hi, On Tue, Feb 24, 2015 at 8:57 AM, stepharo <stepharo@free.fr> wrote:

Doru and Yuriy

String is not a good API for reflective operations. This is what you are doing with asPackage. When I want to access to a class I do Class or Smalltalk globals classNamed: 'Point'

As I said, there is already a String>>asClass. It seems that since it was introduced, people prefer to send Gofer scripts like: #ConfigurationOfXYZ asClass loadDevelopment instead of: (Smalltalk globals classNamed: 'ConfigurationOfXYZ') loadDevelopment a compile method Point>>#x

and not 'Point?x' asCompiledMethod

I think this is not quite the same: one is interpreting a notation and one is looking something up by name.

I would prefer to have Package named: 'jkljk' than the string behavior.

RPackage named: 'XYZ' already exists in the image and is a constructor that returns a new package object without looking it up in the organizer. Perhaps we can add RPackage class>>#@: RPackage @ 'XYZ' Yet, even in that case, working with this would require parentheses: (RPackage @ 'XYZ') linesOfCode I still somehow think that from a reader's point of view, this is more nice: 'XYZ' asPackage linesOfCode and what if I want to reflect on code that is remote?

Package named: 'aaa' would not solve that problem either. Still it would be reasonable solution would be Ok So I maintain that we are polluting String with reflective operations that

it should not have.

I see the point, and I would definitely like to have a first class support for important objects like packages. However, I think the problem is not so black and white. I see string extensions like this as a convenience that enables cheap fluent interfaces. For example, PetitParser relies on this pattern quite successfully. I can delete it from the system if it's so decided, but then we should also remove #asClass. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"