Re: [epsilon-dev] epsilon-dev Digest, Vol 57, Issue 2

[Sina Madani <sm1748@xxxxxxxxxx>]

Yes, this is a key argument. Currently to my understanding the implicit assumption is that models are loaded eagerly upon declaration (hence for example the load method also accepting StringProperties). I don't think I have ever come across an example that doesn't conform to the following:

IModel model = new XModel();

....

model.load(properties);

In a sense, the load method is basically used as a constructor in most cases.

If a model is passed around various methods which execute different Epsilon (or other) programs, they must assume the model has been loaded. If working in asynchronous and lazy environments one has to stretch the semantics of "load()" to make it lazy.

Of course Epsilon has functioned perfectly without isLoaded() and no enhancement requests for it exist on forums or Bugzilla but it's also worth noting that this can be worked around by the application keeping a Set<IModel> to track which ones have been loaded.

I only suggested this as it seems to be a minor omission from the API which is generalisable to every IModel implementation which also implements load(), and every implementation of isLoaded() should in theory be a one-line null check. However for backwards compatibility (despite a major release) we could consider leaving it to the discretion of concrete model implementations instead.

Thanks,

Sina

On Tue, 10 Dec 2019, 16:01 Betty Sanchez, <basp91@xxxxxxxxx> wrote:

Hi all,

I think that an isLoaded() method could be useful in situations where a model is shared across tasks which don’t necessarily know if the model is loaded or not, and could save a potentially expensive re-load operation (such as in Simulink) when the model has been previously loaded, if in doubt.

Regards
Betty

> On 9 Dec 2019, at 17:00, epsilon-dev-request@xxxxxxxxxxx wrote:
>
> Send epsilon-dev mailing list submissions to
>       epsilon-dev@xxxxxxxxxxx
>
> To subscribe or unsubscribe via the World Wide Web, visit
>       https://www.eclipse.org/mailman/listinfo/epsilon-dev
> or, via email, send a message with subject or body 'help' to
>       epsilon-dev-request@xxxxxxxxxxx
>
> You can reach the person managing the list at
>       epsilon-dev-owner@xxxxxxxxxxx
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of epsilon-dev digest..."
>
>
> Today's Topics:
>
>   1. Re: Proposal to add isLoaded() to IModel (Dimitris Kolovos)
>   2. Re: Proposal to add isLoaded to IModel (Sina Madani)
>   3. Re: Proposal to add isLoaded to IModel (Dimitris Kolovos)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 9 Dec 2019 10:39:35 +0000
> From: Dimitris Kolovos <dimitris.kolovos@xxxxxxxxxx>
> To: Epislon Project developer discussions <epsilon-dev@xxxxxxxxxxx>
> Subject: Re: [epsilon-dev] Proposal to add isLoaded() to IModel
> Message-ID:
>       <CAEs3cJiPVLY959tgztiC+7eCWBKxtiBC_PUMhUD6TbDXLuPQ8g@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Sina,
>
> Thanks for the proposal and for investigating its impact. Could you
> briefly summarise a couple of use-cases for this new method? As this
> will be a breaking change (any EMC drivers that we don't control will
> produce compilation errors) it'd be useful to have some justification
> on record.
>
> Thanks,
> Dimitris
>
> On Sat, 7 Dec 2019 at 16:02, Sina Madani <sinadoom@xxxxxxxxxxxxxx> wrote:
>>
>> Hi everyone,
>>
>>
>>
>> I?ve been thinking of adding an isLoaded() method to IModel to determine whether the load() method has been called. As a first step I?ve gone through all EMC drivers that I could find to see how it would work by implementing the method, and without any exception all implementations have been trivial. Every model has an underlying resource which is initialized or mutated when load is called. Therefore the implementation of isLoaded() is, in every case I have encountered, a simple null check. Infact the most ?complex? case is AbstractEmfModel, which is still a one-line _expression_:
>>
>>
>>
>> public boolean isLoaded() {
>>
>>    return modelImpl != null && modelImpl.isLoaded();
>>
>> }
>>
>>
>>
>> Since this is a low-effort method to implement and appears to be very generalisable, combined with the upcoming 2.0 release, I propose to make this an abstract method in IModel.
>>
>>
>>
>> Thanks,
>>
>> Sina
>>
>>
>>
>>
>>
>> _______________________________________________
>> epsilon-dev mailing list
>> epsilon-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/epsilon-dev
>
>
>
> --
> Dimitris Kolovos
> Professor of Software Engineering
> Department of Computer Science
> University of York
> http://www.cs.york.ac.uk/~dkolovos
>
> EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 9 Dec 2019 11:10:56 +0000
> From: Sina Madani <sinadoom@xxxxxxxxxxxxxx>
> To: Epislon Project developer discussions <epsilon-dev@xxxxxxxxxxx>
> Subject: Re: [epsilon-dev] Proposal to add isLoaded to IModel
> Message-ID:
>       <CABPa+unHaWWcYWb-ayFf6bOnLR=Acb_6iwbpTC8CAQ-RD=36kw@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Dimitris,
>
> Thank you for your response. The main rationale is to be able to determine
> a model's state. When given an IModel reference it is currently impossible
> to know whether it is safe to query it because there is no way to know if
> load or dispose has been called. The only option is to try allContents, for
> example, and catch an exception. This is very inefficient however.
>
> If backwards compatibility is a concern perhaps we could make it a default
> method and throw new UnsupportedOperationException, but for any IModel
> which implements load and/or dispose this method is trivial to implement
> and should be implemented.
>
> I think Betty and Horacio or others may also want to chime in here with
> their use cases as it's something I recall being discussed before.
>
> Thanks,
> Sina
>
>
>
>   - *From*: Dimitris Kolovos <dimitris.kolovos@xxxxxxxxxx
>   <dimitris.kolovos@DOMAIN.HIDDEN>>
>   - *Date*: Mon, 9 Dec 2019 10:39:35 +0000
>   - *Delivered-to*: epsilon-dev@xxxxxxxxxxx
>
> Hi Sina,
>
> Thanks for the proposal and for investigating its impact. Could you
> briefly summarise a couple of use-cases for this new method? As this
> will be a breaking change (any EMC drivers that we don't control will
> produce compilation errors) it'd be useful to have some justification
> on record.
>
> Thanks,
> Dimitris
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://www.eclipse.org/mailman/private/epsilon-dev/attachments/20191209/96f9c5f0/attachment.html>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 9 Dec 2019 11:30:50 +0000
> From: Dimitris Kolovos <dimitris.kolovos@xxxxxxxxxx>
> To: Epislon Project developer discussions <epsilon-dev@xxxxxxxxxxx>
> Subject: Re: [epsilon-dev] Proposal to add isLoaded to IModel
> Message-ID:
>       <CAEs3cJhstznCuO6nEPC0JO5v6UtAC7zrZLxEjt9uJqS3YarJWA@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="UTF-8"
>
> Sina,
>
> An UnsupportedOperationException would work around the compilation
> error issue but would produce exceptions at runtime so it's not ideal.
> I understand the rationale of the method; given that it's a breaking
> change, what I'm looking for is a couple of concrete scenarios where
> we need it - i.e. where an Epsilon module is presented with a model
> and it needs to check whether it's loaded. Let's also wait for Betty's
> and Horacio's responses.
>
> Cheers,
> Dimitris
>
>
> On Mon, 9 Dec 2019 at 11:11, Sina Madani <sinadoom@xxxxxxxxxxxxxx> wrote:
>>
>> Hi Dimitris,
>>
>> Thank you for your response. The main rationale is to be able to determine a model's state. When given an IModel reference it is currently impossible to know whether it is safe to query it because there is no way to know if load or dispose has been called. The only option is to try allContents, for example, and catch an exception. This is very inefficient however.
>>
>> If backwards compatibility is a concern perhaps we could make it a default method and throw new UnsupportedOperationException, but for any IModel which implements load and/or dispose this method is trivial to implement and should be implemented.
>>
>> I think Betty and Horacio or others may also want to chime in here with their use cases as it's something I recall being discussed before.
>>
>> Thanks,
>> Sina
>>
>>
>> From: Dimitris Kolovos <dimitris.kolovos@xxxxxxxxxx>
>> Date: Mon, 9 Dec 2019 10:39:35 +0000
>> Delivered-to: epsilon-dev@xxxxxxxxxxx
>>
>> Hi Sina,
>>
>> Thanks for the proposal and for investigating its impact. Could you
>> briefly summarise a couple of use-cases for this new method? As this
>> will be a breaking change (any EMC drivers that we don't control will
>> produce compilation errors) it'd be useful to have some justification
>> on record.
>>
>> Thanks,
>> Dimitris
>>
>> _______________________________________________
>> epsilon-dev mailing list
>> epsilon-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/epsilon-dev
>
>
>
> --
> Dimitris Kolovos
> Professor of Software Engineering
> Department of Computer Science
> University of York
> http://www.cs.york.ac.uk/~dkolovos
>
> EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm
>
>
> ------------------------------
>
> _______________________________________________
> epsilon-dev mailing list
> epsilon-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/epsilon-dev
>
> End of epsilon-dev Digest, Vol 57, Issue 2
> ******************************************

_______________________________________________
epsilon-dev mailing list
epsilon-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/epsilon-dev