Quantcast

Configurable current request context variable

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Configurable current request context variable

Max Leske
Hi,

I would like to use a current request context variable that inherits from DynamicVariable in Pharo and not from WADynamicVariable (I don't want to use the exception mechanism). Hence, I'd like to propose that the current request context variable be made configurable through the configuration mechanism. WACurrentRequestContext could dispatch to the concrete variable to ensure backwards compatibility, e.g.

WACurrentRequestContext>>value
        ^ self concreteVariable value

(WACurrentRequestContext would no longer inherit from WADynamicVariable and have a default variable, e.g. WAConcreteCurrentRequestContext. Sorry for the bad name :) ).

If no one objects, I can implement the change (I'll probably need contributor access).

I'm looking forward to comments.


Cheers,
Max
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configurable current request context variable

Philippe Marschall
On Sat, May 6, 2017 at 5:34 PM, Max Leske <[hidden email]> wrote:
> Hi,
>
> I would like to use a current request context variable that inherits from DynamicVariable in Pharo and not from WADynamicVariable (I don't want to use the exception mechanism).

Can you provide a bit more context? How is it implemented in Pharo? To
with Pharo versions does this apply?

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configurable current request context variable

Max Leske

> On 6 May 2017, at 20:04, Philippe Marschall <[hidden email]> wrote:
>
> On Sat, May 6, 2017 at 5:34 PM, Max Leske <[hidden email]> wrote:
>> Hi,
>>
>> I would like to use a current request context variable that inherits from DynamicVariable in Pharo and not from WADynamicVariable (I don't want to use the exception mechanism).
>
> Can you provide a bit more context? How is it implemented in Pharo? To
> with Pharo versions does this apply?

Sure. DynamicVariables are stored in the environment of the process. They are singletons and the sole instance is used as the lookup key into the process environment dictionary. The access semantics are nearly identical to WADynamicVariable, so they can easily be exchanged. There are two advantages over WADynamicVariable:

1. Access time is constant and no handler context is required
2. The process environment can easily be copied, making it possible to transfer availability of a request context to a different process, e.g. for debugging (I've done that for our own apps in Seaside 2.8)

DynamicVariable has been in Pharo at least since version 1.1.1. and I have been using it in production as a replacement for WACurrentSession from Seaside 2.8 for about two years now.

Cheers,
Max

>
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configurable current request context variable

Philippe Marschall
On Sun, May 7, 2017 at 8:26 AM, Max Leske <[hidden email]> wrote:

>
>> On 6 May 2017, at 20:04, Philippe Marschall <[hidden email]> wrote:
>>
>> On Sat, May 6, 2017 at 5:34 PM, Max Leske <[hidden email]> wrote:
>>> Hi,
>>>
>>> I would like to use a current request context variable that inherits from DynamicVariable in Pharo and not from WADynamicVariable (I don't want to use the exception mechanism).
>>
>> Can you provide a bit more context? How is it implemented in Pharo? To
>> with Pharo versions does this apply?
>
> Sure. DynamicVariables are stored in the environment of the process. They are singletons and the sole instance is used as the lookup key into the process environment dictionary. The access semantics are nearly identical to WADynamicVariable, so they can easily be exchanged. There are two advantages over WADynamicVariable:
>
> 1. Access time is constant and no handler context is required
> 2. The process environment can easily be copied, making it possible to transfer availability of a request context to a different process, e.g. for debugging (I've done that for our own apps in Seaside 2.8)
>
> DynamicVariable has been in Pharo at least since version 1.1.1. and I have been using it in production as a replacement for WACurrentSession from Seaside 2.8 for about two years now.

I see the need but have reservations about the implementation. We have
other dynamic variables which would benefit from this as well.
WADynamicVariable is supposed to be our portable dynamic variable
abstraction.
Do you know what the situation is in the other dialects (GS, VASt, VW)
regarding dynamic variables? Do they have a DynamicVariable class as
well?
In theory we could say that the dialect has to provide a
GRDynamicVariable, we could provide a GRExceptionBasedDynamicVariable.
Dialects that have a DynamicVariable class could provide
GRDynamicVariable as a subclass of DynamicVariable. Dialects that do
not have a DynamicVariable class could provide GRDynamicVariable as a
subclass of GRExceptionBasedDynamicVariable.

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configurable current request context variable

Max Leske

> On 7 May 2017, at 23:09, Philippe Marschall <[hidden email]> wrote:
>
> On Sun, May 7, 2017 at 8:26 AM, Max Leske <[hidden email]> wrote:
>>
>>> On 6 May 2017, at 20:04, Philippe Marschall <[hidden email]> wrote:
>>>
>>> On Sat, May 6, 2017 at 5:34 PM, Max Leske <[hidden email]> wrote:
>>>> Hi,
>>>>
>>>> I would like to use a current request context variable that inherits from DynamicVariable in Pharo and not from WADynamicVariable (I don't want to use the exception mechanism).
>>>
>>> Can you provide a bit more context? How is it implemented in Pharo? To
>>> with Pharo versions does this apply?
>>
>> Sure. DynamicVariables are stored in the environment of the process. They are singletons and the sole instance is used as the lookup key into the process environment dictionary. The access semantics are nearly identical to WADynamicVariable, so they can easily be exchanged. There are two advantages over WADynamicVariable:
>>
>> 1. Access time is constant and no handler context is required
>> 2. The process environment can easily be copied, making it possible to transfer availability of a request context to a different process, e.g. for debugging (I've done that for our own apps in Seaside 2.8)
>>
>> DynamicVariable has been in Pharo at least since version 1.1.1. and I have been using it in production as a replacement for WACurrentSession from Seaside 2.8 for about two years now.
>
> I see the need but have reservations about the implementation. We have
> other dynamic variables which would benefit from this as well.
> WADynamicVariable is supposed to be our portable dynamic variable
> abstraction.
> Do you know what the situation is in the other dialects (GS, VASt, VW)
> regarding dynamic variables? Do they have a DynamicVariable class as
> well?

I have no clue, no (I've never worked with either VA nor VW). I'll try to find out this morning.

> In theory we could say that the dialect has to provide a
> GRDynamicVariable, we could provide a GRExceptionBasedDynamicVariable.
> Dialects that have a DynamicVariable class could provide
> GRDynamicVariable as a subclass of DynamicVariable. Dialects that do
> not have a DynamicVariable class could provide GRDynamicVariable as a
> subclass of GRExceptionBasedDynamicVariable.

Yes, that sounds like a good idea. I don't have a clear picture of how your suggestion would be implemented with Grease. So if you could help me out there, I'd appreciated it.

Cheers,
Max

>
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configurable current request context variable

Max Leske

On 8 May 2017, at 08:57, Max Leske <[hidden email]> wrote:


On 7 May 2017, at 23:09, Philippe Marschall <[hidden email]> wrote:

On Sun, May 7, 2017 at 8:26 AM, Max Leske <[hidden email]> wrote:

On 6 May 2017, at 20:04, Philippe Marschall <[hidden email]> wrote:

On Sat, May 6, 2017 at 5:34 PM, Max Leske <[hidden email]> wrote:
Hi,

I would like to use a current request context variable that inherits from DynamicVariable in Pharo and not from WADynamicVariable (I don't want to use the exception mechanism).

Can you provide a bit more context? How is it implemented in Pharo? To
with Pharo versions does this apply?

Sure. DynamicVariables are stored in the environment of the process. They are singletons and the sole instance is used as the lookup key into the process environment dictionary. The access semantics are nearly identical to WADynamicVariable, so they can easily be exchanged. There are two advantages over WADynamicVariable:

1. Access time is constant and no handler context is required
2. The process environment can easily be copied, making it possible to transfer availability of a request context to a different process, e.g. for debugging (I've done that for our own apps in Seaside 2.8)

DynamicVariable has been in Pharo at least since version 1.1.1. and I have been using it in production as a replacement for WACurrentSession from Seaside 2.8 for about two years now.

I see the need but have reservations about the implementation. We have
other dynamic variables which would benefit from this as well.
WADynamicVariable is supposed to be our portable dynamic variable
abstraction.
Do you know what the situation is in the other dialects (GS, VASt, VW)
regarding dynamic variables? Do they have a DynamicVariable class as
well?

I have no clue, no (I've never worked with either VA nor VW). I'll try to find out this morning.

VW does not have dynamic variables AFAICT, but they do have a process environment, so it would be straight forward to implement them in the same way as in Pharo.

I'm still waiting for my VA evaluation download...


In theory we could say that the dialect has to provide a
GRDynamicVariable, we could provide a GRExceptionBasedDynamicVariable.
Dialects that have a DynamicVariable class could provide
GRDynamicVariable as a subclass of DynamicVariable. Dialects that do
not have a DynamicVariable class could provide GRDynamicVariable as a
subclass of GRExceptionBasedDynamicVariable.

Yes, that sounds like a good idea. I don't have a clear picture of how your suggestion would be implemented with Grease. So if you could help me out there, I'd appreciated it.

Cheers,
Max


Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configurable current request context variable

Philippe Marschall
In reply to this post by Max Leske
On Mon, May 8, 2017 at 8:57 AM, Max Leske <[hidden email]> wrote:

>
>> On 7 May 2017, at 23:09, Philippe Marschall <[hidden email]> wrote:
>> In theory we could say that the dialect has to provide a
>> GRDynamicVariable, we could provide a GRExceptionBasedDynamicVariable.
>> Dialects that have a DynamicVariable class could provide
>> GRDynamicVariable as a subclass of DynamicVariable. Dialects that do
>> not have a DynamicVariable class could provide GRDynamicVariable as a
>> subclass of GRExceptionBasedDynamicVariable.
>
> Yes, that sounds like a good idea. I don't have a clear picture of how your suggestion would be implemented with Grease. So if you could help me out there, I'd appreciated it.

It would be sort of a kludge

In Pharo we would have

DynamicVariable (Pharo)
^
I
GRDynamicVariable (Grease-Pharo-Core)
^
I
WADynamicVariable (Seaside-Core)

In a dialect without dynamic variables we would have

Notification (Dialect)
^
I
GRExceptionBasedDynamicVariable (Grease-Core)
^
I
GRDynamicVariable (Grease-Dialect-Core)
^
I
WADynamicVariable (Seaside-Core)


Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configurable current request context variable

Max Leske
Good news: VA doesn't have dynamic variables either but their process also has an environment (called #attributes). If there's no other platform to look out for, we could simply replicate the DynamicVariable behaviour for each platform without depending on DynamicVariable. There would only be

GRDynamicVariable
^
|
WAPharoDynamicVariable / WAVWDynamicVariable / WAVADynamicVariable

They would only differ in the name of the environment and possibly lookup semantics and GRDynamicVariable could hold all of the logic (it would mostly be a copy of DynamicVariable).

Of course, we could also offer the choice between the exception based and process based variants.

What do you think?

Cheers,
Max



> On 10 May 2017, at 16:44, Philippe Marschall <[hidden email]> wrote:
>
> On Mon, May 8, 2017 at 8:57 AM, Max Leske <[hidden email]> wrote:
>>
>>> On 7 May 2017, at 23:09, Philippe Marschall <[hidden email]> wrote:
>>> In theory we could say that the dialect has to provide a
>>> GRDynamicVariable, we could provide a GRExceptionBasedDynamicVariable.
>>> Dialects that have a DynamicVariable class could provide
>>> GRDynamicVariable as a subclass of DynamicVariable. Dialects that do
>>> not have a DynamicVariable class could provide GRDynamicVariable as a
>>> subclass of GRExceptionBasedDynamicVariable.
>>
>> Yes, that sounds like a good idea. I don't have a clear picture of how your suggestion would be implemented with Grease. So if you could help me out there, I'd appreciated it.
>
> It would be sort of a kludge
>
> In Pharo we would have
>
> DynamicVariable (Pharo)
> ^
> I
> GRDynamicVariable (Grease-Pharo-Core)
> ^
> I
> WADynamicVariable (Seaside-Core)
>
> In a dialect without dynamic variables we would have
>
> Notification (Dialect)
> ^
> I
> GRExceptionBasedDynamicVariable (Grease-Core)
> ^
> I
> GRDynamicVariable (Grease-Dialect-Core)
> ^
> I
> WADynamicVariable (Seaside-Core)
>
>
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configurable current request context variable

Esteban A. Maringolo
What are the benefits of an exception based dynamic variable versus a
process variable?

It seems to me that the process variable is "cleaner" since it doesn't
require any exception handler.

I'm currently doing Seaside in Cincom Smalltalk and I confirm the
Process object has an `environment` variable that holds a dictionary
(and can fallback lookup to a global ProcessEnvironment singleton).

What I don't understand is how would the subclassing work.
If WADynamicVariable is suposed to subclass GRDynamicVariable how
would the platform specific classes play here?

Regards!

Esteban A. Maringolo


2017-05-10 14:16 GMT-03:00 Max Leske <[hidden email]>:

> Good news: VA doesn't have dynamic variables either but their process also has an environment (called #attributes). If there's no other platform to look out for, we could simply replicate the DynamicVariable behaviour for each platform without depending on DynamicVariable. There would only be
>
> GRDynamicVariable
> ^
> |
> WAPharoDynamicVariable / WAVWDynamicVariable / WAVADynamicVariable
>
> They would only differ in the name of the environment and possibly lookup semantics and GRDynamicVariable could hold all of the logic (it would mostly be a copy of DynamicVariable).
>
> Of course, we could also offer the choice between the exception based and process based variants.
>
> What do you think?
>
> Cheers,
> Max
>
>
>
>> On 10 May 2017, at 16:44, Philippe Marschall <[hidden email]> wrote:
>>
>> On Mon, May 8, 2017 at 8:57 AM, Max Leske <[hidden email]> wrote:
>>>
>>>> On 7 May 2017, at 23:09, Philippe Marschall <[hidden email]> wrote:
>>>> In theory we could say that the dialect has to provide a
>>>> GRDynamicVariable, we could provide a GRExceptionBasedDynamicVariable.
>>>> Dialects that have a DynamicVariable class could provide
>>>> GRDynamicVariable as a subclass of DynamicVariable. Dialects that do
>>>> not have a DynamicVariable class could provide GRDynamicVariable as a
>>>> subclass of GRExceptionBasedDynamicVariable.
>>>
>>> Yes, that sounds like a good idea. I don't have a clear picture of how your suggestion would be implemented with Grease. So if you could help me out there, I'd appreciated it.
>>
>> It would be sort of a kludge
>>
>> In Pharo we would have
>>
>> DynamicVariable (Pharo)
>> ^
>> I
>> GRDynamicVariable (Grease-Pharo-Core)
>> ^
>> I
>> WADynamicVariable (Seaside-Core)
>>
>> In a dialect without dynamic variables we would have
>>
>> Notification (Dialect)
>> ^
>> I
>> GRExceptionBasedDynamicVariable (Grease-Core)
>> ^
>> I
>> GRDynamicVariable (Grease-Dialect-Core)
>> ^
>> I
>> WADynamicVariable (Seaside-Core)
>>
>>
>> Cheers
>> Philippe
>> _______________________________________________
>> seaside-dev mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configurable current request context variable

Max Leske

> On 10 May 2017, at 19:55, Esteban A. Maringolo <[hidden email]> wrote:
>
> What are the benefits of an exception based dynamic variable versus a
> process variable?
>
> It seems to me that the process variable is "cleaner" since it doesn't
> require any exception handler.

Exactly. My main concern, however, is performance. Lookup in the process environment takes constant time, while the lookup time of the exception mechanism depends on the depth of the stack and usually requires traversal of multiple handler contexts. In newer VM’s there’s a primitive to help with that but it’s still slower.

>
> I'm currently doing Seaside in Cincom Smalltalk and I confirm the
> Process object has an `environment` variable that holds a dictionary
> (and can fallback lookup to a global ProcessEnvironment singleton).

Thanks.

>
> What I don't understand is how would the subclassing work.
> If WADynamicVariable is suposed to subclass GRDynamicVariable how
> would the platform specific classes play here?

Good point. One way would be to bind the global #WADynamicVariable to a concrete class (e.g. like it has been done in Squeak and Pharo with Transcript or Processor). I don’t like that solution very much. Another could be to have the same class WADynamicVariable defined in multiple packages, i.e., once per platform, where WADynamicVariable implements the platform specific behaviour and inherits from GRDynamicVariable. This solution is better for users but probably a maintenance nightmare.
Another option could be to make WADynamicVariable store a platform specific strategy that is determined dynamically upon load / first use.

I don’t have much experience yet with Seaside and Grease, so I’m hoping that the core maintainers will make the decision for me :) Whatever is implemented, it should probably stay in line with existing platform agnostic solutions used by Grease.


Cheers,
Max


>
> Regards!
>
> Esteban A. Maringolo
>
>
> 2017-05-10 14:16 GMT-03:00 Max Leske <[hidden email]>:
>> Good news: VA doesn't have dynamic variables either but their process also has an environment (called #attributes). If there's no other platform to look out for, we could simply replicate the DynamicVariable behaviour for each platform without depending on DynamicVariable. There would only be
>>
>> GRDynamicVariable
>> ^
>> |
>> WAPharoDynamicVariable / WAVWDynamicVariable / WAVADynamicVariable
>>
>> They would only differ in the name of the environment and possibly lookup semantics and GRDynamicVariable could hold all of the logic (it would mostly be a copy of DynamicVariable).
>>
>> Of course, we could also offer the choice between the exception based and process based variants.
>>
>> What do you think?
>>
>> Cheers,
>> Max
>>
>>
>>
>>> On 10 May 2017, at 16:44, Philippe Marschall <[hidden email]> wrote:
>>>
>>> On Mon, May 8, 2017 at 8:57 AM, Max Leske <[hidden email]> wrote:
>>>>
>>>>> On 7 May 2017, at 23:09, Philippe Marschall <[hidden email]> wrote:
>>>>> In theory we could say that the dialect has to provide a
>>>>> GRDynamicVariable, we could provide a GRExceptionBasedDynamicVariable.
>>>>> Dialects that have a DynamicVariable class could provide
>>>>> GRDynamicVariable as a subclass of DynamicVariable. Dialects that do
>>>>> not have a DynamicVariable class could provide GRDynamicVariable as a
>>>>> subclass of GRExceptionBasedDynamicVariable.
>>>>
>>>> Yes, that sounds like a good idea. I don't have a clear picture of how your suggestion would be implemented with Grease. So if you could help me out there, I'd appreciated it.
>>>
>>> It would be sort of a kludge
>>>
>>> In Pharo we would have
>>>
>>> DynamicVariable (Pharo)
>>> ^
>>> I
>>> GRDynamicVariable (Grease-Pharo-Core)
>>> ^
>>> I
>>> WADynamicVariable (Seaside-Core)
>>>
>>> In a dialect without dynamic variables we would have
>>>
>>> Notification (Dialect)
>>> ^
>>> I
>>> GRExceptionBasedDynamicVariable (Grease-Core)
>>> ^
>>> I
>>> GRDynamicVariable (Grease-Dialect-Core)
>>> ^
>>> I
>>> WADynamicVariable (Seaside-Core)
>>>
>>>
>>> Cheers
>>> Philippe
>>> _______________________________________________
>>> seaside-dev mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>
>> _______________________________________________
>> seaside-dev mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configurable current request context variable

Philippe Marschall
In reply to this post by Esteban A. Maringolo
On Wed, May 10, 2017 at 7:55 PM, Esteban A. Maringolo
<[hidden email]> wrote:
> ..
> What I don't understand is how would the subclassing work.
> If WADynamicVariable is suposed to subclass GRDynamicVariable how
> would the platform specific classes play here?

The idea is that the class GRDynamicVariable is provided by the
Pharo-Dialect-Core package (where "Dialect" is
Pharo/VW/VaST/GemStone).

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configurable current request context variable

Philippe Marschall
On Sun, May 14, 2017 at 9:04 PM, Philippe Marschall
<[hidden email]> wrote:

> On Wed, May 10, 2017 at 7:55 PM, Esteban A. Maringolo
> <[hidden email]> wrote:
>> ..
>> What I don't understand is how would the subclassing work.
>> If WADynamicVariable is suposed to subclass GRDynamicVariable how
>> would the platform specific classes play here?
>
> The idea is that the class GRDynamicVariable is provided by the
> Pharo-Dialect-Core package (where "Dialect" is
> Pharo/VW/VaST/GemStone).

I meant Grease-Dialect-Core.

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configurable current request context variable

Philippe Marschall
In reply to this post by Max Leske
On Wed, May 10, 2017 at 7:16 PM, Max Leske <[hidden email]> wrote:
> Good news: VA doesn't have dynamic variables either but their process also has an environment (called #attributes). If there's no other platform to look out for, we could simply replicate the DynamicVariable behaviour for each platform without depending on DynamicVariable. There would only be
>
> GRDynamicVariable
> ^
> |
> WAPharoDynamicVariable / WAVWDynamicVariable / WAVADynamicVariable

Nope. See my answer to Esteban. The idea is that the dialect specific
implementation of Grease,
Grease-Pharo-Core/Grease-VW-Core/Grease-VaST-Core/Grease-GemStone-Core
would provide a class named GRDynamicVariable. The implementation
would be either process environment based, or dynamic variable based,
or notification based, whatever works best on this dialect. That way
users can simply subclass GRDynamicVariable and automatically get the
best possible behaviour on the dialect they are running on without
having to change their code.

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configurable current request context variable

Max Leske
Hi Philippe,

I’ve created an implementation, trying to do what you suggest; these are the changes:

- removed WADynamicVariable
- added GRDynamicVariable to Grease-Core
- subclasses of WADynamicVariable now inherit from GRDynamicVariable
- test cases for WADynamicVariable moved to Grease-Tests-Core (not sure about this. The tests should be the same for all platforms but Grease-Core does not contain GRDynamicVariable…)

I don’t have write permissions on STHub, so I’m attaching the patches below. I can also make the change for Squeak but I’m not sure how I would go about committing the change for VW / VASt. Let me know what you think.

Cheers,
Max


> On 14 May 2017, at 21:09, Philippe Marschall <[hidden email]> wrote:
>
> On Wed, May 10, 2017 at 7:16 PM, Max Leske <[hidden email]> wrote:
>> Good news: VA doesn't have dynamic variables either but their process also has an environment (called #attributes). If there's no other platform to look out for, we could simply replicate the DynamicVariable behaviour for each platform without depending on DynamicVariable. There would only be
>>
>> GRDynamicVariable
>> ^
>> |
>> WAPharoDynamicVariable / WAVWDynamicVariable / WAVADynamicVariable
>
> Nope. See my answer to Esteban. The idea is that the dialect specific
> implementation of Grease,
> Grease-Pharo-Core/Grease-VW-Core/Grease-VaST-Core/Grease-GemStone-Core
> would provide a class named GRDynamicVariable. The implementation
> would be either process environment based, or dynamic variable based,
> or notification based, whatever works best on this dialect. That way
> users can simply subclass GRDynamicVariable and automatically get the
> best possible behaviour on the dialect they are running on without
> having to change their code.
>
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configurable current request context variable

Esteban A. Maringolo
2017-05-16 17:20 GMT-03:00 Max Leske <[hidden email]>:
> Hi Philippe,
>
> I’ve created an implementation, trying to do what you suggest; these are the changes:
>
> - removed WADynamicVariable
> - added GRDynamicVariable to Grease-Core
> - subclasses of WADynamicVariable now inherit from GRDynamicVariable
> - test cases for WADynamicVariable moved to Grease-Tests-Core (not sure about this. The tests should be the same for all platforms but Grease-Core does not contain GRDynamicVariable…)

Great! Thank you Max.

Is Grease-*Dialect*-Core (e.g. Grease-Pharo-Core) a prerequisite of Grease-Core?


> I don’t have write permissions on STHub, so I’m attaching the patches below.

As expected, the file didn't make it to the attachments of the mail :)

> I can also make the change for Squeak but I’m not sure how I would go about committing the change for VW / VASt. Let me know what you think.




Esteban A. Maringolo
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configurable current request context variable

Max Leske

On 16 May 2017, at 22:24, Esteban A. Maringolo <[hidden email]> wrote:

2017-05-16 17:20 GMT-03:00 Max Leske <[hidden email]>:
Hi Philippe,

I’ve created an implementation, trying to do what you suggest; these are the changes:

- removed WADynamicVariable
- added GRDynamicVariable to Grease-Core

Sorry, this should have been Grease-Pharo30-Core.

- subclasses of WADynamicVariable now inherit from GRDynamicVariable
- test cases for WADynamicVariable moved to Grease-Tests-Core (not sure about this. The tests should be the same for all platforms but Grease-Core does not contain GRDynamicVariable…)

Great! Thank you Max.

Is Grease-*Dialect*-Core (e.g. Grease-Pharo-Core) a prerequisite of Grease-Core?

No, the other way around, according to the configuration.



I don’t have write permissions on STHub, so I’m attaching the patches below.

As expected, the file didn't make it to the attachments of the mail :)

Especially because I forgot to attach them… :p

Here’s the link to a zip archive with the patch: https://www.dropbox.com/s/pgd6k12mwh92s06/GRDynamicVariable_patch.zip?dl=0.

Cheers,
Max


I can also make the change for Squeak but I’m not sure how I would go about committing the change for VW / VASt. Let me know what you think.




Esteban A. Maringolo
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configurable current request context variable

Max Leske
In reply to this post by Esteban A. Maringolo

On 16 May 2017, at 22:24, Esteban A. Maringolo <[hidden email]> wrote:

2017-05-16 17:20 GMT-03:00 Max Leske <[hidden email]>:
Hi Philippe,

I’ve created an implementation, trying to do what you suggest; these are the changes:

- removed WADynamicVariable
- added GRDynamicVariable to Grease-Core

Sorry, this should have been Grease-Pharo30-Core.

- subclasses of WADynamicVariable now inherit from GRDynamicVariable
- test cases for WADynamicVariable moved to Grease-Tests-Core (not sure about this. The tests should be the same for all platforms but Grease-Core does not contain GRDynamicVariable…)

Great! Thank you Max.

Is Grease-*Dialect*-Core (e.g. Grease-Pharo-Core) a prerequisite of Grease-Core?

No, the other way around, according to the configuration.



I don’t have write permissions on STHub, so I’m attaching the patches below.

As expected, the file didn't make it to the attachments of the mail :)

Especially because I forgot to attach them… :p

Here’s the link to a zip archive with the patch: https://www.dropbox.com/s/pgd6k12mwh92s06/GRDynamicVariable_patch.zip?dl=0.

Just remembered something I forgot to fix. New archive: https://www.dropbox.com/s/44smqfnx4cvplt3/GRDynamicVariable_patch2.zip?dl=0.

Max


Cheers,
Max


I can also make the change for Squeak but I’m not sure how I would go about committing the change for VW / VASt. Let me know what you think.




Esteban A. Maringolo
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configurable current request context variable

Johan Brichau-2
Hey Max,

Perhaps you can make a pull request on the git repo?

thx for the work
Johan

On 17 May 2017, at 06:49, Max Leske <[hidden email]> wrote:


On 16 May 2017, at 22:24, Esteban A. Maringolo <[hidden email]> wrote:

2017-05-16 17:20 GMT-03:00 Max Leske <[hidden email]>:
Hi Philippe,

I’ve created an implementation, trying to do what you suggest; these are the changes:

- removed WADynamicVariable
- added GRDynamicVariable to Grease-Core

Sorry, this should have been Grease-Pharo30-Core.

- subclasses of WADynamicVariable now inherit from GRDynamicVariable
- test cases for WADynamicVariable moved to Grease-Tests-Core (not sure about this. The tests should be the same for all platforms but Grease-Core does not contain GRDynamicVariable…)

Great! Thank you Max.

Is Grease-*Dialect*-Core (e.g. Grease-Pharo-Core) a prerequisite of Grease-Core?

No, the other way around, according to the configuration.



I don’t have write permissions on STHub, so I’m attaching the patches below.

As expected, the file didn't make it to the attachments of the mail :)

Especially because I forgot to attach them… :p

Here’s the link to a zip archive with the patch: https://www.dropbox.com/s/pgd6k12mwh92s06/GRDynamicVariable_patch.zip?dl=0.

Just remembered something I forgot to fix. New archive: https://www.dropbox.com/s/44smqfnx4cvplt3/GRDynamicVariable_patch2.zip?dl=0.

Max


Cheers,
Max


I can also make the change for Squeak but I’m not sure how I would go about committing the change for VW / VASt. Let me know what you think.




Esteban A. Maringolo
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configurable current request context variable

Max Leske

On 17 May 2017, at 07:45, Johan Brichau <[hidden email]> wrote:

Hey Max,

Perhaps you can make a pull request on the git repo?

Yes, of course. I wasn't aware that there was a github repository. I'll do that tonight.

Cheers,
Max


thx for the work
Johan

On 17 May 2017, at 06:49, Max Leske <[hidden email]> wrote:


On 16 May 2017, at 22:24, Esteban A. Maringolo <[hidden email]> wrote:

2017-05-16 17:20 GMT-03:00 Max Leske <[hidden email]>:
Hi Philippe,

I’ve created an implementation, trying to do what you suggest; these are the changes:

- removed WADynamicVariable
- added GRDynamicVariable to Grease-Core

Sorry, this should have been Grease-Pharo30-Core.

- subclasses of WADynamicVariable now inherit from GRDynamicVariable
- test cases for WADynamicVariable moved to Grease-Tests-Core (not sure about this. The tests should be the same for all platforms but Grease-Core does not contain GRDynamicVariable…)

Great! Thank you Max.

Is Grease-*Dialect*-Core (e.g. Grease-Pharo-Core) a prerequisite of Grease-Core?

No, the other way around, according to the configuration.



I don’t have write permissions on STHub, so I’m attaching the patches below.

As expected, the file didn't make it to the attachments of the mail :)

Especially because I forgot to attach them… :p

Here’s the link to a zip archive with the patch: https://www.dropbox.com/s/pgd6k12mwh92s06/GRDynamicVariable_patch.zip?dl=0.

Just remembered something I forgot to fix. New archive: https://www.dropbox.com/s/44smqfnx4cvplt3/GRDynamicVariable_patch2.zip?dl=0.

Max


Cheers,
Max


I can also make the change for Squeak but I’m not sure how I would go about committing the change for VW / VASt. Let me know what you think.




Esteban A. Maringolo
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configurable current request context variable

Johan Brichau-2
Great! thanks

Johan

On 17 May 2017, at 07:55, Max Leske <[hidden email]> wrote:


On 17 May 2017, at 07:45, Johan Brichau <[hidden email]> wrote:

Hey Max,

Perhaps you can make a pull request on the git repo?

Yes, of course. I wasn't aware that there was a github repository. I'll do that tonight.

Cheers,
Max


thx for the work
Johan

On 17 May 2017, at 06:49, Max Leske <[hidden email]> wrote:


On 16 May 2017, at 22:24, Esteban A. Maringolo <[hidden email]> wrote:

2017-05-16 17:20 GMT-03:00 Max Leske <[hidden email]>:
Hi Philippe,

I’ve created an implementation, trying to do what you suggest; these are the changes:

- removed WADynamicVariable
- added GRDynamicVariable to Grease-Core

Sorry, this should have been Grease-Pharo30-Core.

- subclasses of WADynamicVariable now inherit from GRDynamicVariable
- test cases for WADynamicVariable moved to Grease-Tests-Core (not sure about this. The tests should be the same for all platforms but Grease-Core does not contain GRDynamicVariable…)

Great! Thank you Max.

Is Grease-*Dialect*-Core (e.g. Grease-Pharo-Core) a prerequisite of Grease-Core?

No, the other way around, according to the configuration.



I don’t have write permissions on STHub, so I’m attaching the patches below.

As expected, the file didn't make it to the attachments of the mail :)

Especially because I forgot to attach them… :p

Here’s the link to a zip archive with the patch: https://www.dropbox.com/s/pgd6k12mwh92s06/GRDynamicVariable_patch.zip?dl=0.

Just remembered something I forgot to fix. New archive: https://www.dropbox.com/s/44smqfnx4cvplt3/GRDynamicVariable_patch2.zip?dl=0.

Max


Cheers,
Max


I can also make the change for Squeak but I’m not sure how I would go about committing the change for VW / VASt. Let me know what you think.




Esteban A. Maringolo
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
12
Loading...