Home » Modeling » Epsilon » EGL's handling of target files
| EGL's handling of target files [message #478847] |
Fri, 07 August 2009 08:52  |
 Steffen Zschaler
Messages: 266
Registered: July 2009 |
Senior Member |
|
|
Hi all,
I'm currently fiddling with EGL a bit, trying to adjust it a bit for my
purposes. In this context, I have noticed what seems to be an
unnecessary redundancy in the EGL code. In particular, this has to do
with how EGL stores the results of generating code from a template,
especially when this code needs to go to a file.
At the moment, this is implemented doubly: Once in EglTask and once in
FileGeneratingTemplate.store. In fact, whenever I need to modify the way
generated code is stored (e.g., because I am using EGL in a different
environment that has its own ideas of how to manage texts), I need to
effectively touch two places: EglTask and an appropriate template
(including its template factory etc.).
I was wondering if it wouldn't be better to change this, so that
EglModule instead of fixedly coding what to do with generated code
(i.e., store it in a string attribute of the module's context) could be
asked to leave this decision to a template instance? This way, there
would only have to be one place where to implement storing of generated
texts. Obviously, every template would have to have a store method (and
we would have to come up with a suitably general parameter set for this
or use a configuration pattern instead), but this would be the only
place affected by any changes to storing generated code.
Do you feel this is a useful enhancement to EGL? Should I file an
enhancement request for it? I might even be able to provide some patches.
Best regards,
Steffen
|
|
|
| Re: EGL's handling of target files [message #478849 is a reply to message #478847] |
Fri, 07 August 2009 09:02  |
Steffen Zschaler
Messages: 266
Registered: July 2009 |
Senior Member |
|
|
Hi again,
Even worse, I just noticed that there is two places in
EglFileGeneratingTemplate that deal with writing to files: generate and
store. Why is this not factored out?
Best,
Steffen
Steffen Zschaler wrote:
> Hi all,
>
> I'm currently fiddling with EGL a bit, trying to adjust it a bit for
> my purposes. In this context, I have noticed what seems to be an
> unnecessary redundancy in the EGL code. In particular, this has to do
> with how EGL stores the results of generating code from a template,
> especially when this code needs to go to a file.
>
> At the moment, this is implemented doubly: Once in EglTask and once in
> FileGeneratingTemplate.store. In fact, whenever I need to modify the
> way generated code is stored (e.g., because I am using EGL in a
> different environment that has its own ideas of how to manage texts),
> I need to effectively touch two places: EglTask and an appropriate
> template (including its template factory etc.).
>
> I was wondering if it wouldn't be better to change this, so that
> EglModule instead of fixedly coding what to do with generated code
> (i.e., store it in a string attribute of the module's context) could
> be asked to leave this decision to a template instance? This way,
> there would only have to be one place where to implement storing of
> generated texts. Obviously, every template would have to have a store
> method (and we would have to come up with a suitably general parameter
> set for this or use a configuration pattern instead), but this would
> be the only place affected by any changes to storing generated code.
>
> Do you feel this is a useful enhancement to EGL? Should I file an
> enhancement request for it? I might even be able to provide some patches.
>
> Best regards,
>
> Steffen
|
|
|
| Re: EGL's handling of target files [message #478854 is a reply to message #478847] |
Fri, 07 August 2009 09:20 |
Steffen Zschaler
Messages: 266
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------070106020806060405050509
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
As I keep moving through this: Is there a way to have EglModule use a
context that I provide? I was hoping that the constructor EglModule
(IEglContext callersContext) would do the trick, but unfortunately this
is foiled by Line 246 (in reset), which creates an instance of
EglContext that shallowly clones the context handed in. Would it be
possible to expose this creation through a factory method
protected IEglContext createContext(IEglContext callerContext)
?
Many thanks,
Steffen
Steffen Zschaler wrote:
> Hi all,
>
> I'm currently fiddling with EGL a bit, trying to adjust it a bit for
> my purposes. In this context, I have noticed what seems to be an
> unnecessary redundancy in the EGL code. In particular, this has to do
> with how EGL stores the results of generating code from a template,
> especially when this code needs to go to a file.
>
> At the moment, this is implemented doubly: Once in EglTask and once in
> FileGeneratingTemplate.store. In fact, whenever I need to modify the
> way generated code is stored (e.g., because I am using EGL in a
> different environment that has its own ideas of how to manage texts),
> I need to effectively touch two places: EglTask and an appropriate
> template (including its template factory etc.).
>
> I was wondering if it wouldn't be better to change this, so that
> EglModule instead of fixedly coding what to do with generated code
> (i.e., store it in a string attribute of the module's context) could
> be asked to leave this decision to a template instance? This way,
> there would only have to be one place where to implement storing of
> generated texts. Obviously, every template would have to have a store
> method (and we would have to come up with a suitably general parameter
> set for this or use a configuration pattern instead), but this would
> be the only place affected by any changes to storing generated code.
>
> Do you feel this is a useful enhancement to EGL? Should I file an
> enhancement request for it? I might even be able to provide some patches.
>
> Best regards,
>
> Steffen
--------------070106020806060405050509
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
As I keep moving through this: Is there a way to have EglModule use a
context that I provide? I was hoping that the constructor EglModule
(IEglContext callersContext) would do the trick, but unfortunately this
is foiled by Line 246 (in reset), which creates an instance of
EglContext that shallowly clones the context handed in. Would it be
possible to expose this creation through a factory method<br>
<blockquote>
<pre>protected IEglContext createContext(IEglContext callerContext)
</pre>
</blockquote>
?<br>
<br>
Many thanks,<br>
<br>
Steffen<br>
<br>
Steffen Zschaler wrote:
<blockquote cite="mid:h5gpvr$vq0$1@build.eclipse.org" type="cite">Hi
all,
<br>
<br>
I'm currently fiddling with EGL a bit, trying to adjust it a bit for my
purposes. In this context, I have noticed what seems to be an
unnecessary redundancy in the EGL code. In particular, this has to do
with how EGL stores the results of generating code from a template,
especially when this code needs to go to a file.
<br>
<br>
At the moment, this is implemented doubly: Once in EglTask and once in
FileGeneratingTemplate.store. In fact, whenever I need to modify the
way generated code is stored (e.g., because I am using EGL in a
different environment that has its own ideas of how to manage texts), I
need to effectively touch two places: EglTask and an appropriate
template (including its template factory etc.).
<br>
<br>
I was wondering if it wouldn't be better to change this, so that
EglModule instead of fixedly coding what to do with generated code
(i.e., store it in a string attribute of the module's context) could be
asked to leave this decision to a template instance? This way, there
would only have to be one place where to implement storing of generated
texts. Obviously, every template would have to have a store method (and
we would have to come up with a suitably general parameter set for this
or use a configuration pattern instead), but this would be the only
place affected by any changes to storing generated code.
<br>
<br>
Do you feel this is a useful enhancement to EGL? Should I file an
enhancement request for it? I might even be able to provide some
patches.
<br>
<br>
Best regards,
<br>
<br>
Steffen
<br>
</blockquote>
</body>
</html>
--------------070106020806060405050509--
|
|
|
| Re: EGL's handling of target files [message #478855 is a reply to message #478849] |
Fri, 07 August 2009 09:26 |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
Hi Steffen,
Yes, I agree, there is some duplication here. Please open an enhancement
request, and I'll perform some refactoring.
To elaborate a little more, the semantics of generate and store are
slightly different: generate respects protected regions, store does not.
Regardless of this difference, there is still some duplication in these
methods. (Originally, store was on a different class, and I probably
didn't spot the duplication after moving the method).
Could you tell me a little more about the way in which you wish to
adjust EGL? It might help to have another use case when considering how
best to change EglFileGeneratingTemplate.
Many thanks,
Louis.
PS - Worse still, EglLaunchConfigurationDelegate also contains some
logic for storing the result of an EglTemplate to file.
Steffen Zschaler wrote:
> Hi again,
>
> Even worse, I just noticed that there is two places in
> EglFileGeneratingTemplate that deal with writing to files: generate and
> store. Why is this not factored out?
>
> Best,
>
> Steffen
>
> Steffen Zschaler wrote:
>> Hi all,
>>
>> I'm currently fiddling with EGL a bit, trying to adjust it a bit for
>> my purposes. In this context, I have noticed what seems to be an
>> unnecessary redundancy in the EGL code. In particular, this has to do
>> with how EGL stores the results of generating code from a template,
>> especially when this code needs to go to a file.
>>
>> At the moment, this is implemented doubly: Once in EglTask and once in
>> FileGeneratingTemplate.store. In fact, whenever I need to modify the
>> way generated code is stored (e.g., because I am using EGL in a
>> different environment that has its own ideas of how to manage texts),
>> I need to effectively touch two places: EglTask and an appropriate
>> template (including its template factory etc.).
>>
>> I was wondering if it wouldn't be better to change this, so that
>> EglModule instead of fixedly coding what to do with generated code
>> (i.e., store it in a string attribute of the module's context) could
>> be asked to leave this decision to a template instance? This way,
>> there would only have to be one place where to implement storing of
>> generated texts. Obviously, every template would have to have a store
>> method (and we would have to come up with a suitably general parameter
>> set for this or use a configuration pattern instead), but this would
>> be the only place affected by any changes to storing generated code.
>>
>> Do you feel this is a useful enhancement to EGL? Should I file an
>> enhancement request for it? I might even be able to provide some patches.
>>
>> Best regards,
>>
>> Steffen
|
|
|
| Re: EGL's handling of target files [message #478858 is a reply to message #478855] |
Fri, 07 August 2009 09:34 |
Steffen Zschaler
Messages: 266
Registered: July 2009 |
Senior Member |
|
|
Hi Louis,
Thanks. I'll open the enhancement request right away.
I don't quite want to talk about my fiddling with EGL (it's not
published yet...), but I'm pretty sure I should be able to give Dimitris
and you a demo at MODELS.
Cheers,
Steffen
Louis Rose wrote:
> Hi Steffen,
>
> Yes, I agree, there is some duplication here. Please open an
> enhancement request, and I'll perform some refactoring.
>
> To elaborate a little more, the semantics of generate and store are
> slightly different: generate respects protected regions, store does
> not. Regardless of this difference, there is still some duplication in
> these methods. (Originally, store was on a different class, and I
> probably didn't spot the duplication after moving the method).
>
> Could you tell me a little more about the way in which you wish to
> adjust EGL? It might help to have another use case when considering
> how best to change EglFileGeneratingTemplate.
>
> Many thanks,
> Louis.
>
> PS - Worse still, EglLaunchConfigurationDelegate also contains some
> logic for storing the result of an EglTemplate to file.
>
> Steffen Zschaler wrote:
>> Hi again,
>>
>> Even worse, I just noticed that there is two places in
>> EglFileGeneratingTemplate that deal with writing to files: generate
>> and store. Why is this not factored out?
>>
>> Best,
>>
>> Steffen
>>
>> Steffen Zschaler wrote:
>>> Hi all,
>>>
>>> I'm currently fiddling with EGL a bit, trying to adjust it a bit for
>>> my purposes. In this context, I have noticed what seems to be an
>>> unnecessary redundancy in the EGL code. In particular, this has to
>>> do with how EGL stores the results of generating code from a
>>> template, especially when this code needs to go to a file.
>>>
>>> At the moment, this is implemented doubly: Once in EglTask and once
>>> in FileGeneratingTemplate.store. In fact, whenever I need to modify
>>> the way generated code is stored (e.g., because I am using EGL in a
>>> different environment that has its own ideas of how to manage
>>> texts), I need to effectively touch two places: EglTask and an
>>> appropriate template (including its template factory etc.).
>>>
>>> I was wondering if it wouldn't be better to change this, so that
>>> EglModule instead of fixedly coding what to do with generated code
>>> (i.e., store it in a string attribute of the module's context) could
>>> be asked to leave this decision to a template instance? This way,
>>> there would only have to be one place where to implement storing of
>>> generated texts. Obviously, every template would have to have a
>>> store method (and we would have to come up with a suitably general
>>> parameter set for this or use a configuration pattern instead), but
>>> this would be the only place affected by any changes to storing
>>> generated code.
>>>
>>> Do you feel this is a useful enhancement to EGL? Should I file an
>>> enhancement request for it? I might even be able to provide some
>>> patches.
>>>
>>> Best regards,
>>>
>>> Steffen
|
|
|
| Re: EGL's handling of target files [message #478859 is a reply to message #478854] |
Fri, 07 August 2009 09:37 |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
That constructor was intended only to be used by the template type, so I
don't think it will do what you want. The way in which contexts are
copied is (another!) part of EGL that I think could use some
refactoring. We could certainly add the method you suggest.
Again, could you explain a little more about what you'd like to achieve?
I'll then use this as motivation for improving the design of the code.
Apologies about the mess! I was a carefree undergraduate when I wrote
EGL; I feel quite ashamed of some of the code now!! Time for some
refactoring...
Cheers,
Louis.
Steffen Zschaler wrote:
> As I keep moving through this: Is there a way to have EglModule use a
> context that I provide? I was hoping that the constructor EglModule
> (IEglContext callersContext) would do the trick, but unfortunately this
> is foiled by Line 246 (in reset), which creates an instance of
> EglContext that shallowly clones the context handed in. Would it be
> possible to expose this creation through a factory method
>
> protected IEglContext createContext(IEglContext callerContext)
>
>
> ?
>
> Many thanks,
>
> Steffen
>
> Steffen Zschaler wrote:
>> Hi all,
>>
>> I'm currently fiddling with EGL a bit, trying to adjust it a bit for
>> my purposes. In this context, I have noticed what seems to be an
>> unnecessary redundancy in the EGL code. In particular, this has to do
>> with how EGL stores the results of generating code from a template,
>> especially when this code needs to go to a file.
>>
>> At the moment, this is implemented doubly: Once in EglTask and once in
>> FileGeneratingTemplate.store. In fact, whenever I need to modify the
>> way generated code is stored (e.g., because I am using EGL in a
>> different environment that has its own ideas of how to manage texts),
>> I need to effectively touch two places: EglTask and an appropriate
>> template (including its template factory etc.).
>>
>> I was wondering if it wouldn't be better to change this, so that
>> EglModule instead of fixedly coding what to do with generated code
>> (i.e., store it in a string attribute of the module's context) could
>> be asked to leave this decision to a template instance? This way,
>> there would only have to be one place where to implement storing of
>> generated texts. Obviously, every template would have to have a store
>> method (and we would have to come up with a suitably general parameter
>> set for this or use a configuration pattern instead), but this would
>> be the only place affected by any changes to storing generated code.
>>
>> Do you feel this is a useful enhancement to EGL? Should I file an
>> enhancement request for it? I might even be able to provide some patches.
>>
>> Best regards,
>>
>> Steffen
|
|
|
| Re: EGL's handling of target files [message #478862 is a reply to message #478858] |
Fri, 07 August 2009 09:42 |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
Hi Steffen,
Steffen Zschaler wrote:
> Hi Louis,
>
> Thanks. I'll open the enhancement request right away.
Thanks. I'll take a look at this on Monday.
>
> I don't quite want to talk about my fiddling with EGL (it's not
> published yet...), but I'm pretty sure I should be able to give Dimitris
> and you a demo at MODELS.
No problem! I can do some initial refactoring now, and then continue
once you've published your work.
Cheers,
Louis.
>
> Cheers,
>
> Steffen
>
> Louis Rose wrote:
>> Hi Steffen,
>>
>> Yes, I agree, there is some duplication here. Please open an
>> enhancement request, and I'll perform some refactoring.
>>
>> To elaborate a little more, the semantics of generate and store are
>> slightly different: generate respects protected regions, store does
>> not. Regardless of this difference, there is still some duplication in
>> these methods. (Originally, store was on a different class, and I
>> probably didn't spot the duplication after moving the method).
>>
>> Could you tell me a little more about the way in which you wish to
>> adjust EGL? It might help to have another use case when considering
>> how best to change EglFileGeneratingTemplate.
>>
>> Many thanks,
>> Louis.
>>
>> PS - Worse still, EglLaunchConfigurationDelegate also contains some
>> logic for storing the result of an EglTemplate to file.
>>
>> Steffen Zschaler wrote:
>>> Hi again,
>>>
>>> Even worse, I just noticed that there is two places in
>>> EglFileGeneratingTemplate that deal with writing to files: generate
>>> and store. Why is this not factored out?
>>>
>>> Best,
>>>
>>> Steffen
>>>
>>> Steffen Zschaler wrote:
>>>> Hi all,
>>>>
>>>> I'm currently fiddling with EGL a bit, trying to adjust it a bit for
>>>> my purposes. In this context, I have noticed what seems to be an
>>>> unnecessary redundancy in the EGL code. In particular, this has to
>>>> do with how EGL stores the results of generating code from a
>>>> template, especially when this code needs to go to a file.
>>>>
>>>> At the moment, this is implemented doubly: Once in EglTask and once
>>>> in FileGeneratingTemplate.store. In fact, whenever I need to modify
>>>> the way generated code is stored (e.g., because I am using EGL in a
>>>> different environment that has its own ideas of how to manage
>>>> texts), I need to effectively touch two places: EglTask and an
>>>> appropriate template (including its template factory etc.).
>>>>
>>>> I was wondering if it wouldn't be better to change this, so that
>>>> EglModule instead of fixedly coding what to do with generated code
>>>> (i.e., store it in a string attribute of the module's context) could
>>>> be asked to leave this decision to a template instance? This way,
>>>> there would only have to be one place where to implement storing of
>>>> generated texts. Obviously, every template would have to have a
>>>> store method (and we would have to come up with a suitably general
>>>> parameter set for this or use a configuration pattern instead), but
>>>> this would be the only place affected by any changes to storing
>>>> generated code.
>>>>
>>>> Do you feel this is a useful enhancement to EGL? Should I file an
>>>> enhancement request for it? I might even be able to provide some
>>>> patches.
>>>>
>>>> Best regards,
>>>>
>>>> Steffen
|
|
|
| Re: EGL's handling of target files [message #478865 is a reply to message #478858] |
Fri, 07 August 2009 09:59 |
Steffen Zschaler
Messages: 266
Registered: July 2009 |
Senior Member |
|
|
And here is the enhancement request:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=285977
Cheers,
Steffen
Steffen Zschaler wrote:
> Hi Louis,
>
> Thanks. I'll open the enhancement request right away.
>
> I don't quite want to talk about my fiddling with EGL (it's not
> published yet...), but I'm pretty sure I should be able to give
> Dimitris and you a demo at MODELS.
>
> Cheers,
>
> Steffen
>
> Louis Rose wrote:
>> Hi Steffen,
>>
>> Yes, I agree, there is some duplication here. Please open an
>> enhancement request, and I'll perform some refactoring.
>>
>> To elaborate a little more, the semantics of generate and store are
>> slightly different: generate respects protected regions, store does
>> not. Regardless of this difference, there is still some duplication
>> in these methods. (Originally, store was on a different class, and I
>> probably didn't spot the duplication after moving the method).
>>
>> Could you tell me a little more about the way in which you wish to
>> adjust EGL? It might help to have another use case when considering
>> how best to change EglFileGeneratingTemplate.
>>
>> Many thanks,
>> Louis.
>>
>> PS - Worse still, EglLaunchConfigurationDelegate also contains some
>> logic for storing the result of an EglTemplate to file.
>>
>> Steffen Zschaler wrote:
>>> Hi again,
>>>
>>> Even worse, I just noticed that there is two places in
>>> EglFileGeneratingTemplate that deal with writing to files: generate
>>> and store. Why is this not factored out?
>>>
>>> Best,
>>>
>>> Steffen
>>>
>>> Steffen Zschaler wrote:
>>>> Hi all,
>>>>
>>>> I'm currently fiddling with EGL a bit, trying to adjust it a bit
>>>> for my purposes. In this context, I have noticed what seems to be
>>>> an unnecessary redundancy in the EGL code. In particular, this has
>>>> to do with how EGL stores the results of generating code from a
>>>> template, especially when this code needs to go to a file.
>>>>
>>>> At the moment, this is implemented doubly: Once in EglTask and once
>>>> in FileGeneratingTemplate.store. In fact, whenever I need to modify
>>>> the way generated code is stored (e.g., because I am using EGL in a
>>>> different environment that has its own ideas of how to manage
>>>> texts), I need to effectively touch two places: EglTask and an
>>>> appropriate template (including its template factory etc.).
>>>>
>>>> I was wondering if it wouldn't be better to change this, so that
>>>> EglModule instead of fixedly coding what to do with generated code
>>>> (i.e., store it in a string attribute of the module's context)
>>>> could be asked to leave this decision to a template instance? This
>>>> way, there would only have to be one place where to implement
>>>> storing of generated texts. Obviously, every template would have to
>>>> have a store method (and we would have to come up with a suitably
>>>> general parameter set for this or use a configuration pattern
>>>> instead), but this would be the only place affected by any changes
>>>> to storing generated code.
>>>>
>>>> Do you feel this is a useful enhancement to EGL? Should I file an
>>>> enhancement request for it? I might even be able to provide some
>>>> patches.
>>>>
>>>> Best regards,
>>>>
>>>> Steffen
|
|
|
| Re: EGL's handling of target files [message #478875 is a reply to message #478855] |
Fri, 07 August 2009 10:20 |
Steffen Zschaler
Messages: 266
Registered: July 2009 |
Senior Member |
|
|
Hi Louis (again),
Louis Rose wrote:
<snip />
> To elaborate a little more, the semantics of generate and store are
> slightly different: generate respects protected regions, store does
> not. Regardless of this difference, there is still some duplication in
> these methods. (Originally, store was on a different class, and I
> probably didn't spot the duplication after moving the method).
I'm not entirely sure I understand why the two methods are needed. When
would I ever want to write out without the protected-regions mechanism?
It would seem to me that this is actually a quite dangerous option to
have, because it could potentially break the encapsulation of the
template being invoked: If that template contains statements for
creating protected regions, but is then called using store() these
protected regions would effectively be lost. This seems like an error
easily made, but very difficult to spot...
Also, I just had another look at the EpsilonBook, and this only ever
mentions store. generate is not mentioned there at all (although it is
mentioned in some of the examples available, yet without further
explanation). This may need some fixing.
Cheers,
Steffen
|
|
|
| Re: EGL's handling of target files [message #478880 is a reply to message #478865] |
Fri, 07 August 2009 10:47 |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
Thanks! I'll get to this on Monday. (I've learnt through experience that
I should never refactor on a Friday!)
Steffen Zschaler wrote:
> And here is the enhancement request:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=285977
>
> Cheers,
>
> Steffen
>
> Steffen Zschaler wrote:
>> Hi Louis,
>>
>> Thanks. I'll open the enhancement request right away.
>>
>> I don't quite want to talk about my fiddling with EGL (it's not
>> published yet...), but I'm pretty sure I should be able to give
>> Dimitris and you a demo at MODELS.
>>
>> Cheers,
>>
>> Steffen
>>
>> Louis Rose wrote:
>>> Hi Steffen,
>>>
>>> Yes, I agree, there is some duplication here. Please open an
>>> enhancement request, and I'll perform some refactoring.
>>>
>>> To elaborate a little more, the semantics of generate and store are
>>> slightly different: generate respects protected regions, store does
>>> not. Regardless of this difference, there is still some duplication
>>> in these methods. (Originally, store was on a different class, and I
>>> probably didn't spot the duplication after moving the method).
>>>
>>> Could you tell me a little more about the way in which you wish to
>>> adjust EGL? It might help to have another use case when considering
>>> how best to change EglFileGeneratingTemplate.
>>>
>>> Many thanks,
>>> Louis.
>>>
>>> PS - Worse still, EglLaunchConfigurationDelegate also contains some
>>> logic for storing the result of an EglTemplate to file.
>>>
>>> Steffen Zschaler wrote:
>>>> Hi again,
>>>>
>>>> Even worse, I just noticed that there is two places in
>>>> EglFileGeneratingTemplate that deal with writing to files: generate
>>>> and store. Why is this not factored out?
>>>>
>>>> Best,
>>>>
>>>> Steffen
>>>>
>>>> Steffen Zschaler wrote:
>>>>> Hi all,
>>>>>
>>>>> I'm currently fiddling with EGL a bit, trying to adjust it a bit
>>>>> for my purposes. In this context, I have noticed what seems to be
>>>>> an unnecessary redundancy in the EGL code. In particular, this has
>>>>> to do with how EGL stores the results of generating code from a
>>>>> template, especially when this code needs to go to a file.
>>>>>
>>>>> At the moment, this is implemented doubly: Once in EglTask and once
>>>>> in FileGeneratingTemplate.store. In fact, whenever I need to modify
>>>>> the way generated code is stored (e.g., because I am using EGL in a
>>>>> different environment that has its own ideas of how to manage
>>>>> texts), I need to effectively touch two places: EglTask and an
>>>>> appropriate template (including its template factory etc.).
>>>>>
>>>>> I was wondering if it wouldn't be better to change this, so that
>>>>> EglModule instead of fixedly coding what to do with generated code
>>>>> (i.e., store it in a string attribute of the module's context)
>>>>> could be asked to leave this decision to a template instance? This
>>>>> way, there would only have to be one place where to implement
>>>>> storing of generated texts. Obviously, every template would have to
>>>>> have a store method (and we would have to come up with a suitably
>>>>> general parameter set for this or use a configuration pattern
>>>>> instead), but this would be the only place affected by any changes
>>>>> to storing generated code.
>>>>>
>>>>> Do you feel this is a useful enhancement to EGL? Should I file an
>>>>> enhancement request for it? I might even be able to provide some
>>>>> patches.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Steffen
|
|
|
| Re: EGL's handling of target files [message #478883 is a reply to message #478875] |
Fri, 07 August 2009 10:53 |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
Steffen Zschaler wrote:
> Hi Louis (again),
>
> Louis Rose wrote:
> <snip />
>> To elaborate a little more, the semantics of generate and store are
>> slightly different: generate respects protected regions, store does
>> not. Regardless of this difference, there is still some duplication in
>> these methods. (Originally, store was on a different class, and I
>> probably didn't spot the duplication after moving the method).
> I'm not entirely sure I understand why the two methods are needed. When
> would I ever want to write out without the protected-regions mechanism?
> It would seem to me that this is actually a quite dangerous option to
> have, because it could potentially break the encapsulation of the
> template being invoked: If that template contains statements for
> creating protected regions, but is then called using store() these
> protected regions would effectively be lost. This seems like an error
> easily made, but very difficult to spot...
Actually, my initial description is a little wrong: store/1 fails
gracefully when a file already exists. Passing true as the second
parameter of store/2 cause the target to be overwritten (regardless of
protected regions). generate respects protected regions, and performs a
plain store/1 when the target doesn't exist.
I'll take a look at our acceptance tests, my undergraduate thesis, and
EGLDoc to see whether store/2 is being used. If not, removing it may
simplify this refactoring.
>
> Also, I just had another look at the EpsilonBook, and this only ever
> mentions store. generate is not mentioned there at all (although it is
> mentioned in some of the examples available, yet without further
> explanation). This may need some fixing.
>
Thanks for the information. I agree, this needs to be fixed. I'll add a
note to the enhancement request.
Cheers,
Louis.
|
|
|
| Re: EGL's handling of target files [message #479062 is a reply to message #478883] |
Sat, 08 August 2009 17:34 |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
Louis Rose wrote:
> Steffen Zschaler wrote:
>> Hi Louis (again),
>>
>> Louis Rose wrote:
>> <snip />
>>> To elaborate a little more, the semantics of generate and store are
>>> slightly different: generate respects protected regions, store does
>>> not. Regardless of this difference, there is still some duplication
>>> in these methods. (Originally, store was on a different class, and I
>>> probably didn't spot the duplication after moving the method).
>> I'm not entirely sure I understand why the two methods are needed.
>> When would I ever want to write out without the protected-regions
>> mechanism? It would seem to me that this is actually a quite dangerous
>> option to have, because it could potentially break the encapsulation
>> of the template being invoked: If that template contains statements
>> for creating protected regions, but is then called using store() these
>> protected regions would effectively be lost. This seems like an error
>> easily made, but very difficult to spot...
>
> Actually, my initial description is a little wrong: store/1 fails
> gracefully when a file already exists. Passing true as the second
> parameter of store/2 cause the target to be overwritten (regardless of
> protected regions). generate respects protected regions, and performs a
> plain store/1 when the target doesn't exist.
>
> I'll take a look at our acceptance tests, my undergraduate thesis, and
> EGLDoc to see whether store/2 is being used. If not, removing it may
> simplify this refactoring.
>
Some more on this: store is no more useful than generate in any of our
acceptance tests, nor in EGLDoc. Consequently, it's highly likely that
we will deprecate it, see:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=286050
|
|
|
| Re: EGL's handling of target files [message #479063 is a reply to message #478865] |
Sat, 08 August 2009 17:44 |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
I've added some notes on a possible refactoring to the bug report.
Steffen Zschaler wrote:
> And here is the enhancement request:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=285977
>
> Cheers,
>
> Steffen
>
> Steffen Zschaler wrote:
>> Hi Louis,
>>
>> Thanks. I'll open the enhancement request right away.
>>
>> I don't quite want to talk about my fiddling with EGL (it's not
>> published yet...), but I'm pretty sure I should be able to give
>> Dimitris and you a demo at MODELS.
>>
>> Cheers,
>>
>> Steffen
>>
>> Louis Rose wrote:
>>> Hi Steffen,
>>>
>>> Yes, I agree, there is some duplication here. Please open an
>>> enhancement request, and I'll perform some refactoring.
>>>
>>> To elaborate a little more, the semantics of generate and store are
>>> slightly different: generate respects protected regions, store does
>>> not. Regardless of this difference, there is still some duplication
>>> in these methods. (Originally, store was on a different class, and I
>>> probably didn't spot the duplication after moving the method).
>>>
>>> Could you tell me a little more about the way in which you wish to
>>> adjust EGL? It might help to have another use case when considering
>>> how best to change EglFileGeneratingTemplate.
>>>
>>> Many thanks,
>>> Louis.
>>>
>>> PS - Worse still, EglLaunchConfigurationDelegate also contains some
>>> logic for storing the result of an EglTemplate to file.
>>>
>>> Steffen Zschaler wrote:
>>>> Hi again,
>>>>
>>>> Even worse, I just noticed that there is two places in
>>>> EglFileGeneratingTemplate that deal with writing to files: generate
>>>> and store. Why is this not factored out?
>>>>
>>>> Best,
>>>>
>>>> Steffen
>>>>
>>>> Steffen Zschaler wrote:
>>>>> Hi all,
>>>>>
>>>>> I'm currently fiddling with EGL a bit, trying to adjust it a bit
>>>>> for my purposes. In this context, I have noticed what seems to be
>>>>> an unnecessary redundancy in the EGL code. In particular, this has
>>>>> to do with how EGL stores the results of generating code from a
>>>>> template, especially when this code needs to go to a file.
>>>>>
>>>>> At the moment, this is implemented doubly: Once in EglTask and once
>>>>> in FileGeneratingTemplate.store. In fact, whenever I need to modify
>>>>> the way generated code is stored (e.g., because I am using EGL in a
>>>>> different environment that has its own ideas of how to manage
>>>>> texts), I need to effectively touch two places: EglTask and an
>>>>> appropriate template (including its template factory etc.).
>>>>>
>>>>> I was wondering if it wouldn't be better to change this, so that
>>>>> EglModule instead of fixedly coding what to do with generated code
>>>>> (i.e., store it in a string attribute of the module's context)
>>>>> could be asked to leave this decision to a template instance? This
>>>>> way, there would only have to be one place where to implement
>>>>> storing of generated texts. Obviously, every template would have to
>>>>> have a store method (and we would have to come up with a suitably
>>>>> general parameter set for this or use a configuration pattern
>>>>> instead), but this would be the only place affected by any changes
>>>>> to storing generated code.
>>>>>
>>>>> Do you feel this is a useful enhancement to EGL? Should I file an
>>>>> enhancement request for it? I might even be able to provide some
>>>>> patches.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Steffen
|
|
|
| Re: EGL's handling of target files [message #572697 is a reply to message #478847] |
Fri, 07 August 2009 09:02 |
Steffen Zschaler
Messages: 266
Registered: July 2009 |
Senior Member |
|
|
Hi again,
Even worse, I just noticed that there is two places in
EglFileGeneratingTemplate that deal with writing to files: generate and
store. Why is this not factored out?
Best,
Steffen
Steffen Zschaler wrote:
> Hi all,
>
> I'm currently fiddling with EGL a bit, trying to adjust it a bit for
> my purposes. In this context, I have noticed what seems to be an
> unnecessary redundancy in the EGL code. In particular, this has to do
> with how EGL stores the results of generating code from a template,
> especially when this code needs to go to a file.
>
> At the moment, this is implemented doubly: Once in EglTask and once in
> FileGeneratingTemplate.store. In fact, whenever I need to modify the
> way generated code is stored (e.g., because I am using EGL in a
> different environment that has its own ideas of how to manage texts),
> I need to effectively touch two places: EglTask and an appropriate
> template (including its template factory etc.).
>
> I was wondering if it wouldn't be better to change this, so that
> EglModule instead of fixedly coding what to do with generated code
> (i.e., store it in a string attribute of the module's context) could
> be asked to leave this decision to a template instance? This way,
> there would only have to be one place where to implement storing of
> generated texts. Obviously, every template would have to have a store
> method (and we would have to come up with a suitably general parameter
> set for this or use a configuration pattern instead), but this would
> be the only place affected by any changes to storing generated code.
>
> Do you feel this is a useful enhancement to EGL? Should I file an
> enhancement request for it? I might even be able to provide some patches.
>
> Best regards,
>
> Steffen
|
|
|
| Re: EGL's handling of target files [message #572713 is a reply to message #478847] |
Fri, 07 August 2009 09:20 |
Steffen Zschaler
Messages: 266
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------070106020806060405050509
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
As I keep moving through this: Is there a way to have EglModule use a
context that I provide? I was hoping that the constructor EglModule
(IEglContext callersContext) would do the trick, but unfortunately this
is foiled by Line 246 (in reset), which creates an instance of
EglContext that shallowly clones the context handed in. Would it be
possible to expose this creation through a factory method
protected IEglContext createContext(IEglContext callerContext)
?
Many thanks,
Steffen
Steffen Zschaler wrote:
> Hi all,
>
> I'm currently fiddling with EGL a bit, trying to adjust it a bit for
> my purposes. In this context, I have noticed what seems to be an
> unnecessary redundancy in the EGL code. In particular, this has to do
> with how EGL stores the results of generating code from a template,
> especially when this code needs to go to a file.
>
> At the moment, this is implemented doubly: Once in EglTask and once in
> FileGeneratingTemplate.store. In fact, whenever I need to modify the
> way generated code is stored (e.g., because I am using EGL in a
> different environment that has its own ideas of how to manage texts),
> I need to effectively touch two places: EglTask and an appropriate
> template (including its template factory etc.).
>
> I was wondering if it wouldn't be better to change this, so that
> EglModule instead of fixedly coding what to do with generated code
> (i.e., store it in a string attribute of the module's context) could
> be asked to leave this decision to a template instance? This way,
> there would only have to be one place where to implement storing of
> generated texts. Obviously, every template would have to have a store
> method (and we would have to come up with a suitably general parameter
> set for this or use a configuration pattern instead), but this would
> be the only place affected by any changes to storing generated code.
>
> Do you feel this is a useful enhancement to EGL? Should I file an
> enhancement request for it? I might even be able to provide some patches.
>
> Best regards,
>
> Steffen
--------------070106020806060405050509
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
As I keep moving through this: Is there a way to have EglModule use a
context that I provide? I was hoping that the constructor EglModule
(IEglContext callersContext) would do the trick, but unfortunately this
is foiled by Line 246 (in reset), which creates an instance of
EglContext that shallowly clones the context handed in. Would it be
possible to expose this creation through a factory method<br>
<blockquote>
<pre>protected IEglContext createContext(IEglContext callerContext)
</pre>
</blockquote>
?<br>
<br>
Many thanks,<br>
<br>
Steffen<br>
<br>
Steffen Zschaler wrote:
<blockquote cite="mid:h5gpvr$vq0$1@build.eclipse.org" type="cite">Hi
all,
<br>
<br>
I'm currently fiddling with EGL a bit, trying to adjust it a bit for my
purposes. In this context, I have noticed what seems to be an
unnecessary redundancy in the EGL code. In particular, this has to do
with how EGL stores the results of generating code from a template,
especially when this code needs to go to a file.
<br>
<br>
At the moment, this is implemented doubly: Once in EglTask and once in
FileGeneratingTemplate.store. In fact, whenever I need to modify the
way generated code is stored (e.g., because I am using EGL in a
different environment that has its own ideas of how to manage texts), I
need to effectively touch two places: EglTask and an appropriate
template (including its template factory etc.).
<br>
<br>
I was wondering if it wouldn't be better to change this, so that
EglModule instead of fixedly coding what to do with generated code
(i.e., store it in a string attribute of the module's context) could be
asked to leave this decision to a template instance? This way, there
would only have to be one place where to implement storing of generated
texts. Obviously, every template would have to have a store method (and
we would have to come up with a suitably general parameter set for this
or use a configuration pattern instead), but this would be the only
place affected by any changes to storing generated code.
<br>
<br>
Do you feel this is a useful enhancement to EGL? Should I file an
enhancement request for it? I might even be able to provide some
patches.
<br>
<br>
Best regards,
<br>
<br>
Steffen
<br>
</blockquote>
</body>
</html>
--------------070106020806060405050509--
|
|
|
| Re: EGL's handling of target files [message #572731 is a reply to message #478849] |
Fri, 07 August 2009 09:26 |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
Hi Steffen,
Yes, I agree, there is some duplication here. Please open an enhancement
request, and I'll perform some refactoring.
To elaborate a little more, the semantics of generate and store are
slightly different: generate respects protected regions, store does not.
Regardless of this difference, there is still some duplication in these
methods. (Originally, store was on a different class, and I probably
didn't spot the duplication after moving the method).
Could you tell me a little more about the way in which you wish to
adjust EGL? It might help to have another use case when considering how
best to change EglFileGeneratingTemplate.
Many thanks,
Louis.
PS - Worse still, EglLaunchConfigurationDelegate also contains some
logic for storing the result of an EglTemplate to file.
Steffen Zschaler wrote:
> Hi again,
>
> Even worse, I just noticed that there is two places in
> EglFileGeneratingTemplate that deal with writing to files: generate and
> store. Why is this not factored out?
>
> Best,
>
> Steffen
>
> Steffen Zschaler wrote:
>> Hi all,
>>
>> I'm currently fiddling with EGL a bit, trying to adjust it a bit for
>> my purposes. In this context, I have noticed what seems to be an
>> unnecessary redundancy in the EGL code. In particular, this has to do
>> with how EGL stores the results of generating code from a template,
>> especially when this code needs to go to a file.
>>
>> At the moment, this is implemented doubly: Once in EglTask and once in
>> FileGeneratingTemplate.store. In fact, whenever I need to modify the
>> way generated code is stored (e.g., because I am using EGL in a
>> different environment that has its own ideas of how to manage texts),
>> I need to effectively touch two places: EglTask and an appropriate
>> template (including its template factory etc.).
>>
>> I was wondering if it wouldn't be better to change this, so that
>> EglModule instead of fixedly coding what to do with generated code
>> (i.e., store it in a string attribute of the module's context) could
>> be asked to leave this decision to a template instance? This way,
>> there would only have to be one place where to implement storing of
>> generated texts. Obviously, every template would have to have a store
>> method (and we would have to come up with a suitably general parameter
>> set for this or use a configuration pattern instead), but this would
>> be the only place affected by any changes to storing generated code.
>>
>> Do you feel this is a useful enhancement to EGL? Should I file an
>> enhancement request for it? I might even be able to provide some patches.
>>
>> Best regards,
>>
>> Steffen
|
|
|
| Re: EGL's handling of target files [message #572743 is a reply to message #478855] |
Fri, 07 August 2009 09:34 |
Steffen Zschaler
Messages: 266
Registered: July 2009 |
Senior Member |
|
|
Hi Louis,
Thanks. I'll open the enhancement request right away.
I don't quite want to talk about my fiddling with EGL (it's not
published yet...), but I'm pretty sure I should be able to give Dimitris
and you a demo at MODELS.
Cheers,
Steffen
Louis Rose wrote:
> Hi Steffen,
>
> Yes, I agree, there is some duplication here. Please open an
> enhancement request, and I'll perform some refactoring.
>
> To elaborate a little more, the semantics of generate and store are
> slightly different: generate respects protected regions, store does
> not. Regardless of this difference, there is still some duplication in
> these methods. (Originally, store was on a different class, and I
> probably didn't spot the duplication after moving the method).
>
> Could you tell me a little more about the way in which you wish to
> adjust EGL? It might help to have another use case when considering
> how best to change EglFileGeneratingTemplate.
>
> Many thanks,
> Louis.
>
> PS - Worse still, EglLaunchConfigurationDelegate also contains some
> logic for storing the result of an EglTemplate to file.
>
> Steffen Zschaler wrote:
>> Hi again,
>>
>> Even worse, I just noticed that there is two places in
>> EglFileGeneratingTemplate that deal with writing to files: generate
>> and store. Why is this not factored out?
>>
>> Best,
>>
>> Steffen
>>
>> Steffen Zschaler wrote:
>>> Hi all,
>>>
>>> I'm currently fiddling with EGL a bit, trying to adjust it a bit for
>>> my purposes. In this context, I have noticed what seems to be an
>>> unnecessary redundancy in the EGL code. In particular, this has to
>>> do with how EGL stores the results of generating code from a
>>> template, especially when this code needs to go to a file.
>>>
>>> At the moment, this is implemented doubly: Once in EglTask and once
>>> in FileGeneratingTemplate.store. In fact, whenever I need to modify
>>> the way generated code is stored (e.g., because I am using EGL in a
>>> different environment that has its own ideas of how to manage
>>> texts), I need to effectively touch two places: EglTask and an
>>> appropriate template (including its template factory etc.).
>>>
>>> I was wondering if it wouldn't be better to change this, so that
>>> EglModule instead of fixedly coding what to do with generated code
>>> (i.e., store it in a string attribute of the module's context) could
>>> be asked to leave this decision to a template instance? This way,
>>> there would only have to be one place where to implement storing of
>>> generated texts. Obviously, every template would have to have a
>>> store method (and we would have to come up with a suitably general
>>> parameter set for this or use a configuration pattern instead), but
>>> this would be the only place affected by any changes to storing
>>> generated code.
>>>
>>> Do you feel this is a useful enhancement to EGL? Should I file an
>>> enhancement request for it? I might even be able to provide some
>>> patches.
>>>
>>> Best regards,
>>>
>>> Steffen
|
|
|
| Re: EGL's handling of target files [message #572760 is a reply to message #478854] |
Fri, 07 August 2009 09:37 |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
That constructor was intended only to be used by the template type, so I
don't think it will do what you want. The way in which contexts are
copied is (another!) part of EGL that I think could use some
refactoring. We could certainly add the method you suggest.
Again, could you explain a little more about what you'd like to achieve?
I'll then use this as motivation for improving the design of the code.
Apologies about the mess! I was a carefree undergraduate when I wrote
EGL; I feel quite ashamed of some of the code now!! Time for some
refactoring...
Cheers,
Louis.
Steffen Zschaler wrote:
> As I keep moving through this: Is there a way to have EglModule use a
> context that I provide? I was hoping that the constructor EglModule
> (IEglContext callersContext) would do the trick, but unfortunately this
> is foiled by Line 246 (in reset), which creates an instance of
> EglContext that shallowly clones the context handed in. Would it be
> possible to expose this creation through a factory method
>
> protected IEglContext createContext(IEglContext callerContext)
>
>
> ?
>
> Many thanks,
>
> Steffen
>
> Steffen Zschaler wrote:
>> Hi all,
>>
>> I'm currently fiddling with EGL a bit, trying to adjust it a bit for
>> my purposes. In this context, I have noticed what seems to be an
>> unnecessary redundancy in the EGL code. In particular, this has to do
>> with how EGL stores the results of generating code from a template,
>> especially when this code needs to go to a file.
>>
>> At the moment, this is implemented doubly: Once in EglTask and once in
>> FileGeneratingTemplate.store. In fact, whenever I need to modify the
>> way generated code is stored (e.g., because I am using EGL in a
>> different environment that has its own ideas of how to manage texts),
>> I need to effectively touch two places: EglTask and an appropriate
>> template (including its template factory etc.).
>>
>> I was wondering if it wouldn't be better to change this, so that
>> EglModule instead of fixedly coding what to do with generated code
>> (i.e., store it in a string attribute of the module's context) could
>> be asked to leave this decision to a template instance? This way,
>> there would only have to be one place where to implement storing of
>> generated texts. Obviously, every template would have to have a store
>> method (and we would have to come up with a suitably general parameter
>> set for this or use a configuration pattern instead), but this would
>> be the only place affected by any changes to storing generated code.
>>
>> Do you feel this is a useful enhancement to EGL? Should I file an
>> enhancement request for it? I might even be able to provide some patches.
>>
>> Best regards,
>>
>> Steffen
|
|
|
| Re: EGL's handling of target files [message #572779 is a reply to message #478858] |
Fri, 07 August 2009 09:42 |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
Hi Steffen,
Steffen Zschaler wrote:
> Hi Louis,
>
> Thanks. I'll open the enhancement request right away.
Thanks. I'll take a look at this on Monday.
>
> I don't quite want to talk about my fiddling with EGL (it's not
> published yet...), but I'm pretty sure I should be able to give Dimitris
> and you a demo at MODELS.
No problem! I can do some initial refactoring now, and then continue
once you've published your work.
Cheers,
Louis.
>
> Cheers,
>
> Steffen
>
> Louis Rose wrote:
>> Hi Steffen,
>>
>> Yes, I agree, there is some duplication here. Please open an
>> enhancement request, and I'll perform some refactoring.
>>
>> To elaborate a little more, the semantics of generate and store are
>> slightly different: generate respects protected regions, store does
>> not. Regardless of this difference, there is still some duplication in
>> these methods. (Originally, store was on a different class, and I
>> probably didn't spot the duplication after moving the method).
>>
>> Could you tell me a little more about the way in which you wish to
>> adjust EGL? It might help to have another use case when considering
>> how best to change EglFileGeneratingTemplate.
>>
>> Many thanks,
>> Louis.
>>
>> PS - Worse still, EglLaunchConfigurationDelegate also contains some
>> logic for storing the result of an EglTemplate to file.
>>
>> Steffen Zschaler wrote:
>>> Hi again,
>>>
>>> Even worse, I just noticed that there is two places in
>>> EglFileGeneratingTemplate that deal with writing to files: generate
>>> and store. Why is this not factored out?
>>>
>>> Best,
>>>
>>> Steffen
>>>
>>> Steffen Zschaler wrote:
>>>> Hi all,
>>>>
>>>> I'm currently fiddling with EGL a bit, trying to adjust it a bit for
>>>> my purposes. In this context, I have noticed what seems to be an
>>>> unnecessary redundancy in the EGL code. In particular, this has to
>>>> do with how EGL stores the results of generating code from a
>>>> template, especially when this code needs to go to a file.
>>>>
>>>> At the moment, this is implemented doubly: Once in EglTask and once
>>>> in FileGeneratingTemplate.store. In fact, whenever I need to modify
>>>> the way generated code is stored (e.g., because I am using EGL in a
>>>> different environment that has its own ideas of how to manage
>>>> texts), I need to effectively touch two places: EglTask and an
>>>> appropriate template (including its template factory etc.).
>>>>
>>>> I was wondering if it wouldn't be better to change this, so that
>>>> EglModule instead of fixedly coding what to do with generated code
>>>> (i.e., store it in a string attribute of the module's context) could
>>>> be asked to leave this decision to a template instance? This way,
>>>> there would only have to be one place where to implement storing of
>>>> generated texts. Obviously, every template would have to have a
>>>> store method (and we would have to come up with a suitably general
>>>> parameter set for this or use a configuration pattern instead), but
>>>> this would be the only place affected by any changes to storing
>>>> generated code.
>>>>
>>>> Do you feel this is a useful enhancement to EGL? Should I file an
>>>> enhancement request for it? I might even be able to provide some
>>>> patches.
>>>>
>>>> Best regards,
>>>>
>>>> Steffen
|
|
|
| Re: EGL's handling of target files [message #572800 is a reply to message #478858] |
Fri, 07 August 2009 09:59 |
Steffen Zschaler
Messages: 266
Registered: July 2009 |
Senior Member |
|
|
And here is the enhancement request:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=285977
Cheers,
Steffen
Steffen Zschaler wrote:
> Hi Louis,
>
> Thanks. I'll open the enhancement request right away.
>
> I don't quite want to talk about my fiddling with EGL (it's not
> published yet...), but I'm pretty sure I should be able to give
> Dimitris and you a demo at MODELS.
>
> Cheers,
>
> Steffen
>
> Louis Rose wrote:
>> Hi Steffen,
>>
>> Yes, I agree, there is some duplication here. Please open an
>> enhancement request, and I'll perform some refactoring.
>>
>> To elaborate a little more, the semantics of generate and store are
>> slightly different: generate respects protected regions, store does
>> not. Regardless of this difference, there is still some duplication
>> in these methods. (Originally, store was on a different class, and I
>> probably didn't spot the duplication after moving the method).
>>
>> Could you tell me a little more about the way in which you wish to
>> adjust EGL? It might help to have another use case when considering
>> how best to change EglFileGeneratingTemplate.
>>
>> Many thanks,
>> Louis.
>>
>> PS - Worse still, EglLaunchConfigurationDelegate also contains some
>> logic for storing the result of an EglTemplate to file.
>>
>> Steffen Zschaler wrote:
>>> Hi again,
>>>
>>> Even worse, I just noticed that there is two places in
>>> EglFileGeneratingTemplate that deal with writing to files: generate
>>> and store. Why is this not factored out?
>>>
>>> Best,
>>>
>>> Steffen
>>>
>>> Steffen Zschaler wrote:
>>>> Hi all,
>>>>
>>>> I'm currently fiddling with EGL a bit, trying to adjust it a bit
>>>> for my purposes. In this context, I have noticed what seems to be
>>>> an unnecessary redundancy in the EGL code. In particular, this has
>>>> to do with how EGL stores the results of generating code from a
>>>> template, especially when this code needs to go to a file.
>>>>
>>>> At the moment, this is implemented doubly: Once in EglTask and once
>>>> in FileGeneratingTemplate.store. In fact, whenever I need to modify
>>>> the way generated code is stored (e.g., because I am using EGL in a
>>>> different environment that has its own ideas of how to manage
>>>> texts), I need to effectively touch two places: EglTask and an
>>>> appropriate template (including its template factory etc.).
>>>>
>>>> I was wondering if it wouldn't be better to change this, so that
>>>> EglModule instead of fixedly coding what to do with generated code
>>>> (i.e., store it in a string attribute of the module's context)
>>>> could be asked to leave this decision to a template instance? This
>>>> way, there would only have to be one place where to implement
>>>> storing of generated texts. Obviously, every template would have to
>>>> have a store method (and we would have to come up with a suitably
>>>> general parameter set for this or use a configuration pattern
>>>> instead), but this would be the only place affected by any changes
>>>> to storing generated code.
>>>>
>>>> Do you feel this is a useful enhancement to EGL? Should I file an
>>>> enhancement request for it? I might even be able to provide some
>>>> patches.
>>>>
>>>> Best regards,
>>>>
>>>> Steffen
|
|
|
| Re: EGL's handling of target files [message #572849 is a reply to message #478855] |
Fri, 07 August 2009 10:20 |
Steffen Zschaler
Messages: 266
Registered: July 2009 |
Senior Member |
|
|
Hi Louis (again),
Louis Rose wrote:
<snip />
> To elaborate a little more, the semantics of generate and store are
> slightly different: generate respects protected regions, store does
> not. Regardless of this difference, there is still some duplication in
> these methods. (Originally, store was on a different class, and I
> probably didn't spot the duplication after moving the method).
I'm not entirely sure I understand why the two methods are needed. When
would I ever want to write out without the protected-regions mechanism?
It would seem to me that this is actually a quite dangerous option to
have, because it could potentially break the encapsulation of the
template being invoked: If that template contains statements for
creating protected regions, but is then called using store() these
protected regions would effectively be lost. This seems like an error
easily made, but very difficult to spot...
Also, I just had another look at the EpsilonBook, and this only ever
mentions store. generate is not mentioned there at all (although it is
mentioned in some of the examples available, yet without further
explanation). This may need some fixing.
Cheers,
Steffen
|
|
|
| Re: EGL's handling of target files [message #572955 is a reply to message #478865] |
Fri, 07 August 2009 10:47 |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
Thanks! I'll get to this on Monday. (I've learnt through experience that
I should never refactor on a Friday!)
Steffen Zschaler wrote:
> And here is the enhancement request:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=285977
>
> Cheers,
>
> Steffen
>
> Steffen Zschaler wrote:
>> Hi Louis,
>>
>> Thanks. I'll open the enhancement request right away.
>>
>> I don't quite want to talk about my fiddling with EGL (it's not
>> published yet...), but I'm pretty sure I should be able to give
>> Dimitris and you a demo at MODELS.
>>
>> Cheers,
>>
>> Steffen
>>
>> Louis Rose wrote:
>>> Hi Steffen,
>>>
>>> Yes, I agree, there is some duplication here. Please open an
>>> enhancement request, and I'll perform some refactoring.
>>>
>>> To elaborate a little more, the semantics of generate and store are
>>> slightly different: generate respects protected regions, store does
>>> not. Regardless of this difference, there is still some duplication
>>> in these methods. (Originally, store was on a different class, and I
>>> probably didn't spot the duplication after moving the method).
>>>
>>> Could you tell me a little more about the way in which you wish to
>>> adjust EGL? It might help to have another use case when considering
>>> how best to change EglFileGeneratingTemplate.
>>>
>>> Many thanks,
>>> Louis.
>>>
>>> PS - Worse still, EglLaunchConfigurationDelegate also contains some
>>> logic for storing the result of an EglTemplate to file.
>>>
>>> Steffen Zschaler wrote:
>>>> Hi again,
>>>>
>>>> Even worse, I just noticed that there is two places in
>>>> EglFileGeneratingTemplate that deal with writing to files: generate
>>>> and store. Why is this not factored out?
>>>>
>>>> Best,
>>>>
>>>> Steffen
>>>>
>>>> Steffen Zschaler wrote:
>>>>> Hi all,
>>>>>
>>>>> I'm currently fiddling with EGL a bit, trying to adjust it a bit
>>>>> for my purposes. In this context, I have noticed what seems to be
>>>>> an unnecessary redundancy in the EGL code. In particular, this has
>>>>> to do with how EGL stores the results of generating code from a
>>>>> template, especially when this code needs to go to a file.
>>>>>
>>>>> At the moment, this is implemented doubly: Once in EglTask and once
>>>>> in FileGeneratingTemplate.store. In fact, whenever I need to modify
>>>>> the way generated code is stored (e.g., because I am using EGL in a
>>>>> different environment that has its own ideas of how to manage
>>>>> texts), I need to effectively touch two places: EglTask and an
>>>>> appropriate template (including its template factory etc.).
>>>>>
>>>>> I was wondering if it wouldn't be better to change this, so that
>>>>> EglModule instead of fixedly coding what to do with generated code
>>>>> (i.e., store it in a string attribute of the module's context)
>>>>> could be asked to leave this decision to a template instance? This
>>>>> way, there would only have to be one place where to implement
>>>>> storing of generated texts. Obviously, every template would have to
>>>>> have a store method (and we would have to come up with a suitably
>>>>> general parameter set for this or use a configuration pattern
>>>>> instead), but this would be the only place affected by any changes
>>>>> to storing generated code.
>>>>>
>>>>> Do you feel this is a useful enhancement to EGL? Should I file an
>>>>> enhancement request for it? I might even be able to provide some
>>>>> patches.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Steffen
|
|
|
| Re: EGL's handling of target files [message #572989 is a reply to message #478875] |
Fri, 07 August 2009 10:53 |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
Steffen Zschaler wrote:
> Hi Louis (again),
>
> Louis Rose wrote:
> <snip />
>> To elaborate a little more, the semantics of generate and store are
>> slightly different: generate respects protected regions, store does
>> not. Regardless of this difference, there is still some duplication in
>> these methods. (Originally, store was on a different class, and I
>> probably didn't spot the duplication after moving the method).
> I'm not entirely sure I understand why the two methods are needed. When
> would I ever want to write out without the protected-regions mechanism?
> It would seem to me that this is actually a quite dangerous option to
> have, because it could potentially break the encapsulation of the
> template being invoked: If that template contains statements for
> creating protected regions, but is then called using store() these
> protected regions would effectively be lost. This seems like an error
> easily made, but very difficult to spot...
Actually, my initial description is a little wrong: store/1 fails
gracefully when a file already exists. Passing true as the second
parameter of store/2 cause the target to be overwritten (regardless of
protected regions). generate respects protected regions, and performs a
plain store/1 when the target doesn't exist.
I'll take a look at our acceptance tests, my undergraduate thesis, and
EGLDoc to see whether store/2 is being used. If not, removing it may
simplify this refactoring.
>
> Also, I just had another look at the EpsilonBook, and this only ever
> mentions store. generate is not mentioned there at all (although it is
> mentioned in some of the examples available, yet without further
> explanation). This may need some fixing.
>
Thanks for the information. I agree, this needs to be fixed. I'll add a
note to the enhancement request.
Cheers,
Louis.
|
|
|
| Re: EGL's handling of target files [message #573219 is a reply to message #478883] |
Sat, 08 August 2009 17:34 |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
Louis Rose wrote:
> Steffen Zschaler wrote:
>> Hi Louis (again),
>>
>> Louis Rose wrote:
>> <snip />
>>> To elaborate a little more, the semantics of generate and store are
>>> slightly different: generate respects protected regions, store does
>>> not. Regardless of this difference, there is still some duplication
>>> in these methods. (Originally, store was on a different class, and I
>>> probably didn't spot the duplication after moving the method).
>> I'm not entirely sure I understand why the two methods are needed.
>> When would I ever want to write out without the protected-regions
>> mechanism? It would seem to me that this is actually a quite dangerous
>> option to have, because it could potentially break the encapsulation
>> of the template being invoked: If that template contains statements
>> for creating protected regions, but is then called using store() these
>> protected regions would effectively be lost. This seems like an error
>> easily made, but very difficult to spot...
>
> Actually, my initial description is a little wrong: store/1 fails
> gracefully when a file already exists. Passing true as the second
> parameter of store/2 cause the target to be overwritten (regardless of
> protected regions). generate respects protected regions, and performs a
> plain store/1 when the target doesn't exist.
>
> I'll take a look at our acceptance tests, my undergraduate thesis, and
> EGLDoc to see whether store/2 is being used. If not, removing it may
> simplify this refactoring.
>
Some more on this: store is no more useful than generate in any of our
acceptance tests, nor in EGLDoc. Consequently, it's highly likely that
we will deprecate it, see:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=286050
|
|
|
| Re: EGL's handling of target files [message #573230 is a reply to message #478865] |
Sat, 08 August 2009 17:44 |
Louis Rose
Messages: 440
Registered: July 2009
Location: York, United Kingdom |
Senior Member |
|
|
I've added some notes on a possible refactoring to the bug report.
Steffen Zschaler wrote:
> And here is the enhancement request:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=285977
>
> Cheers,
>
> Steffen
>
> Steffen Zschaler wrote:
>> Hi Louis,
>>
>> Thanks. I'll open the enhancement request right away.
>>
>> I don't quite want to talk about my fiddling with EGL (it's not
>> published yet...), but I'm pretty sure I should be able to give
>> Dimitris and you a demo at MODELS.
>>
>> Cheers,
>>
>> Steffen
>>
>> Louis Rose wrote:
>>> Hi Steffen,
>>>
>>> Yes, I agree, there is some duplication here. Please open an
>>> enhancement request, and I'll perform some refactoring.
>>>
>>> To elaborate a little more, the semantics of generate and store are
>>> slightly different: generate respects protected regions, store does
>>> not. Regardless of this difference, there is still some duplication
>>> in these methods. (Originally, store was on a different class, and I
>>> probably didn't spot the duplication after moving the method).
>>>
>>> Could you tell me a little more about the way in which you wish to
>>> adjust EGL? It might help to have another use case when considering
>>> how best to change EglFileGeneratingTemplate.
>>>
>>> Many thanks,
>>> Louis.
>>>
>>> PS - Worse still, EglLaunchConfigurationDelegate also contains some
>>> logic for storing the result of an EglTemplate to file.
>>>
>>> Steffen Zschaler wrote:
>>>> Hi again,
>>>>
>>>> Even worse, I just noticed that there is two places in
>>>> EglFileGeneratingTemplate that deal with writing to files: generate
>>>> and store. Why is this not factored out?
>>>>
>>>> Best,
>>>>
>>>> Steffen
>>>>
>>>> Steffen Zschaler wrote:
>>>>> Hi all,
>>>>>
>>>>> I'm currently fiddling with EGL a bit, trying to adjust it a bit
>>>>> for my purposes. In this context, I have noticed what seems to be
>>>>> an unnecessary redundancy in the EGL code. In particular, this has
>>>>> to do with how EGL stores the results of generating code from a
>>>>> template, especially when this code needs to go to a file.
>>>>>
>>>>> At the moment, this is implemented doubly: Once in EglTask and once
>>>>> in FileGeneratingTemplate.store. In fact, whenever I need to modify
>>>>> the way generated code is stored (e.g., because I am using EGL in a
>>>>> different environment that has its own ideas of how to manage
>>>>> texts), I need to effectively touch two places: EglTask and an
>>>>> appropriate template (including its template factory etc.).
>>>>>
>>>>> I was wondering if it wouldn't be better to change this, so that
>>>>> EglModule instead of fixedly coding what to do with generated code
>>>>> (i.e., store it in a string attribute of the module's context)
>>>>> could be asked to leave this decision to a template instance? This
>>>>> way, there would only have to be one place where to implement
>>>>> storing of generated texts. Obviously, every template would have to
>>>>> have a store method (and we would have to come up with a suitably
>>>>> general parameter set for this or use a configuration pattern
>>>>> instead), but this would be the only place affected by any changes
>>>>> to storing generated code.
>>>>>
>>>>> Do you feel this is a useful enhancement to EGL? Should I file an
>>>>> enhancement request for it? I might even be able to provide some
>>>>> patches.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Steffen
|
|
|
Goto Forum:
Current Time: Sat Apr 27 02:47:55 GMT 2024
Powered by FUDForum. Page generated in 0.05289 seconds |
] 
Search
Help
Register
Login
Home
