Home » Modeling » EMF » Abstract methods
| |
| Re: Abstract methods [message #429667 is a reply to message #429633] |
Tue, 28 April 2009 23:05   |
 Bob
Messages: 44
Registered: July 2009 |
Member |
|
|
Hi Ed,
I've got to digest/understand what you are saying.
In the mean time some clarification, the reason for the modified generators
is to separate generated code from hand written code.
Some responses follow.
"Ed Merks" <Ed.Merks@gmail.com> wrote in message
news:gt6ngc$tud$1@build.eclipse.org...
> Bob,
>
> Comments below.
>
>
> Bob wrote:
>> Hi all,
>>
>> I've seen some discussions on this topic but not quite what I'm after.
>>
>> If I have an abstract class with abstract methods I would like to have
>> those abstract methods implemented in subclasses. However, it seems ecore
>> does not support abstract methods. This is not necessarily a problem, all
>> methods defined in the abstract class can just be generated in the
>> sub-class.
>>
> EMF will always generate a stub implementation of the method. Of course
> you can change it to @generated NOT and mark it as abstract instead of
> implementing it.
Yes, in the abstract class it will, but I don't want to be editing generated
code. I'm surprised still that the model wouldn't provide support for
abstract methods, what is the reasoning behind this?
>> We currently have written some of our own JET templates to alter the code
>> generation so that methods defined in the model get generated with a line
>> of code that calls a static method where our custom code is:
>>
>> /**
>>
>> * <!-- begin-user-doc -->
>>
>> * <!-- end-user-doc -->
>>
>> * @model
>>
>> * @generated
>>
>> */
>>
>> public void abstractMethod() {
>>
>> TestModel.TestModel.AbstractClassBridge.abstractMethod(this) ;
>>
>> }
>>
> Did you know you can specify a method body as an EAnnotation on the
> EOperation? GenOperationImpl accesses it like this:
>
> protected String getBody()
> {
> EOperation eOperation = getEcoreOperation();
> EAnnotation eAnnotation =
> eOperation.getEAnnotation(GenModelPackage.eNS_URI);
> return eAnnotation == null ? null :
> (String)eAnnotation.getDetails().get("body");
> }
>
>>
>>
>> So I think my ideal solution would be just to have this method also
>> generated in the subclasses, but by default the method isn't.
> If all the subclasses have the same method, why have copies everywhere?
They have the same method (signature) but not the same implementation.
Particularly if it was an abstract method in the super class this makes
perfect sense.
> Subclasses that want an override could define the operation again with a
> body EAnnotation and could suppress the redundant declaration from the
> interface using another EAnnotation
> (EcoreUtil.setSuppressedVisibility(EOperation, boolean)).
>
> This way you'd not need specialized templates...
I'll follow this up, I don't understand it but have the EMF book version 2
so I'm sure this is explained in there.
Thanks
Lionel.
|
|
|
| Re: Abstract methods [message #429668 is a reply to message #429667] |
Tue, 28 April 2009 23:18 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------020804030503030201030200
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Bob,
Comments below.
Bob wrote:
> Hi Ed,
>
> I've got to digest/understand what you are saying.
>
I've been accused of being like a fire hose....
> In the mean time some clarification, the reason for the modified generators
> is to separate generated code from hand written code.
>
Separation of hand written and generated code seems to be one of those
"religious" types of things. Personally, I'm more of a peanut butter
cup kind of guy: if chocolate and peanut butter go good together, why
separate them?
Annotations can help by capturing the hand written code in the model
itself...
> Some responses follow.
>
> "Ed Merks" <Ed.Merks@gmail.com> wrote in message
> news:gt6ngc$tud$1@build.eclipse.org...
>
>> Bob,
>>
>> Comments below.
>>
>>
>> Bob wrote:
>>
>>> Hi all,
>>>
>>> I've seen some discussions on this topic but not quite what I'm after.
>>>
>>> If I have an abstract class with abstract methods I would like to have
>>> those abstract methods implemented in subclasses. However, it seems ecore
>>> does not support abstract methods. This is not necessarily a problem, all
>>> methods defined in the abstract class can just be generated in the
>>> sub-class.
>>>
>>>
>> EMF will always generate a stub implementation of the method. Of course
>> you can change it to @generated NOT and mark it as abstract instead of
>> implementing it.
>>
>
> Yes, in the abstract class it will, but I don't want to be editing generated
> code.
It goes again the religion which says: never the twain shall meet...
> I'm surprised still that the model wouldn't provide support for
> abstract methods, what is the reasoning behind this?
>
Because Ecore is a high level abstraction for defining the API. It's
not just simplified Java...
>
>
>>> We currently have written some of our own JET templates to alter the code
>>> generation so that methods defined in the model get generated with a line
>>> of code that calls a static method where our custom code is:
>>>
>>> /**
>>>
>>> * <!-- begin-user-doc -->
>>>
>>> * <!-- end-user-doc -->
>>>
>>> * @model
>>>
>>> * @generated
>>>
>>> */
>>>
>>> public void abstractMethod() {
>>>
>>> TestModel.TestModel.AbstractClassBridge.abstractMethod(this) ;
>>>
>>> }
>>>
>>>
>> Did you know you can specify a method body as an EAnnotation on the
>> EOperation? GenOperationImpl accesses it like this:
>>
>> protected String getBody()
>> {
>> EOperation eOperation = getEcoreOperation();
>> EAnnotation eAnnotation =
>> eOperation.getEAnnotation(GenModelPackage.eNS_URI);
>> return eAnnotation == null ? null :
>> (String)eAnnotation.getDetails().get("body");
>> }
>>
>>
>>> So I think my ideal solution would be just to have this method also
>>> generated in the subclasses, but by default the method isn't.
>>>
>> If all the subclasses have the same method, why have copies everywhere?
>>
>
> They have the same method (signature) but not the same implementation.
>
Ecore is more about defining the API and much less about defining the
implementation, which is typically better done in a programming language
like Java.
> Particularly if it was an abstract method in the super class this makes
> perfect sense.
>
From a Java perspective. An implementation that throws an exception
"this isn't implemented" isn't logically all that much different, other
than the Java compile time constraints associated with it...
>
>> Subclasses that want an override could define the operation again with a
>> body EAnnotation and could suppress the redundant declaration from the
>> interface using another EAnnotation
>> (EcoreUtil.setSuppressedVisibility(EOperation, boolean)).
>>
>> This way you'd not need specialized templates...
>>
>
> I'll follow this up, I don't understand it but have the EMF book version 2
> so I'm sure this is explained in there.
>
Dave is very meticulous. He rarely misses a detail...
> Thanks
>
> Lionel.
>
>
>
--------------020804030503030201030200
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">
Bob,<br>
<br>
Comments below.<br>
<br>
Bob wrote:
<blockquote cite="mid:gt823d$3gv$1@build.eclipse.org" type="cite">
<pre wrap="">Hi Ed,
I've got to digest/understand what you are saying.
</pre>
</blockquote>
I've been accused of being like a fire hose....<br>
<blockquote cite="mid:gt823d$3gv$1@build.eclipse.org" type="cite">
<pre wrap="">
In the mean time some clarification, the reason for the modified generators
is to separate generated code from hand written code.
</pre>
</blockquote>
Separation of hand written and generated code seems to be one of those
"religious" types of things. Personally, I'm more of a peanut butter
cup kind of guy: if chocolate and peanut butter go good together, why
separate them? <br>
<br>
Annotations can help by capturing the hand written code in the model
itself...<br>
<blockquote cite="mid:gt823d$3gv$1@build.eclipse.org" type="cite">
<pre wrap="">
Some responses follow.
"Ed Merks" <a class="moz-txt-link-rfc2396E" href="mailto:Ed.Merks@gmail.com"><Ed.Merks@gmail.com></a> wrote in message
<a class="moz-txt-link-freetext" href="news:gt6ngc$tud$1@build.eclipse.org">news:gt6ngc$tud$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Bob,
Comments below.
Bob wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,
I've seen some discussions on this topic but not quite what I'm after.
If I have an abstract class with abstract methods I would like to have
those abstract methods implemented in subclasses. However, it seems ecore
does not support abstract methods. This is not necessarily a problem, all
methods defined in the abstract class can just be generated in the
sub-class.
</pre>
</blockquote>
<pre wrap="">EMF will always generate a stub implementation of the method. Of course
you can change it to @generated NOT and mark it as abstract instead of
implementing it.
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, in the abstract class it will, but I don't want to be editing generated
code. </pre>
</blockquote>
It goes again the religion which says: never the twain shall meet...<br>
<blockquote cite="mid:gt823d$3gv$1@build.eclipse.org" type="cite">
<pre wrap="">I'm surprised still that the model wouldn't provide support for
abstract methods, what is the reasoning behind this?
</pre>
</blockquote>
Because Ecore is a high level abstraction for defining the API. It's
not just simplified Java...<br>
<blockquote cite="mid:gt823d$3gv$1@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">We currently have written some of our own JET templates to alter the code
generation so that methods defined in the model get generated with a line
of code that calls a static method where our custom code is:
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @model
* @generated
*/
public void abstractMethod() {
TestModel.TestModel.AbstractClassBridge.abstractMethod(this) ;
}
</pre>
</blockquote>
<pre wrap="">Did you know you can specify a method body as an EAnnotation on the
EOperation? GenOperationImpl accesses it like this:
protected String getBody()
{
EOperation eOperation = getEcoreOperation();
EAnnotation eAnnotation =
eOperation.getEAnnotation(GenModelPackage.eNS_URI);
return eAnnotation == null ? null :
(String)eAnnotation.getDetails().get("body");
}
</pre>
<blockquote type="cite">
<pre wrap="">
So I think my ideal solution would be just to have this method also
generated in the subclasses, but by default the method isn't.
</pre>
</blockquote>
<pre wrap="">If all the subclasses have the same method, why have copies everywhere?
</pre>
</blockquote>
<pre wrap=""><!---->
They have the same method (signature) but not the same implementation.
</pre>
</blockquote>
Ecore is more about defining the API and much less about defining the
implementation, which is typically better done in a programming
language like Java.<br>
<blockquote cite="mid:gt823d$3gv$1@build.eclipse.org" type="cite">
<pre wrap="">Particularly if it was an abstract method in the super class this makes
perfect sense.
</pre>
</blockquote>
From a Java perspective. An implementation that throws an exception
"this isn't implemented" isn't logically all that much different, other
than the Java compile time constraints associated with it...<br>
<blockquote cite="mid:gt823d$3gv$1@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Subclasses that want an override could define the operation again with a
body EAnnotation and could suppress the redundant declaration from the
interface using another EAnnotation
(EcoreUtil.setSuppressedVisibility(EOperation, boolean)).
This way you'd not need specialized templates...
</pre>
</blockquote>
<pre wrap=""><!---->
I'll follow this up, I don't understand it but have the EMF book version 2
so I'm sure this is explained in there.
</pre>
</blockquote>
Dave is very meticulous. He rarely misses a detail...<br>
<blockquote cite="mid:gt823d$3gv$1@build.eclipse.org" type="cite">
<pre wrap="">
Thanks
Lionel.
</pre>
</blockquote>
</body>
</html>
--------------020804030503030201030200--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Abstract methods [message #429669 is a reply to message #429668] |
Wed, 29 April 2009 00:14 |
Bob
Messages: 44
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0049_01C9C8B3.404F9BB0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Ed,
Unfortunately OE is being an absolute pain and so I can't easily respond =
inline. I also can't remember username ans password so I can't setup =
Thunderbird :(. So bear with me while I try to respond.
I'm not going to get into the hand written code separation argument. =
Let's just say that it's a requirement of my project, and leave it =
there.
>> Particularly if it was an abstract method in the super class this =
makes=20
>> perfect sense.
> From a Java perspective. An implementation that throws an exception =
"this isn't implemented" isn't logically all
> that much different, other than the Java compile time constraints =
associated with it...
But the implementation is/should be much different from that in my case.
Anyway, I shall follow up with these annotations and see if I can work =
them to do what I need.
Thanks
Lionel.
"Ed Merks" <Ed.Merks@gmail.com> wrote in message =
news:49F78EA8.20201@gmail.com...
Bob,
Comments below.
Bob wrote:=20
Hi Ed,
I've got to digest/understand what you are saying.
I've been accused of being like a fire hose....
In the mean time some clarification, the reason for the modified =
generators=20
is to separate generated code from hand written code.
Separation of hand written and generated code seems to be one of those =
"religious" types of things. Personally, I'm more of a peanut butter =
cup kind of guy: if chocolate and peanut butter go good together, why =
separate them? =20
Annotations can help by capturing the hand written code in the model =
itself...
Some responses follow.
"Ed Merks" <Ed.Merks@gmail.com> wrote in message=20
news:gt6ngc$tud$1@build.eclipse.org...
Bob,
Comments below.
Bob wrote:
Hi all,
I've seen some discussions on this topic but not quite what I'm after.
If I have an abstract class with abstract methods I would like to have=20
those abstract methods implemented in subclasses. However, it seems =
ecore=20
does not support abstract methods. This is not necessarily a problem, =
all=20
methods defined in the abstract class can just be generated in the=20
sub-class.
EMF will always generate a stub implementation of the method. Of =
course=20
you can change it to @generated NOT and mark it as abstract instead of=20
implementing it.
=20
Yes, in the abstract class it will, but I don't want to be editing =
generated=20
code. It goes again the religion which says: never the twain shall =
meet...
I'm surprised still that the model wouldn't provide support for=20
abstract methods, what is the reasoning behind this?
Because Ecore is a high level abstraction for defining the API. It's =
not just simplified Java...
We currently have written some of our own JET templates to alter the =
code=20
generation so that methods defined in the model get generated with a =
line=20
of code that calls a static method where our custom code is:
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @model
* @generated
*/
public void abstractMethod() {
TestModel.TestModel.AbstractClassBridge.abstractMethod(this) ;
}
Did you know you can specify a method body as an EAnnotation on =
the=20
EOperation? GenOperationImpl accesses it like this:
protected String getBody()
{
EOperation eOperation =3D getEcoreOperation();
EAnnotation eAnnotation =3D=20
eOperation.getEAnnotation(GenModelPackage.eNS_URI);
return eAnnotation =3D=3D null ? null :=20
(String)eAnnotation.getDetails().get("body");
}
So I think my ideal solution would be just to have this method also=20
generated in the subclasses, but by default the method isn't.
If all the subclasses have the same method, why have copies =
everywhere?
=20
They have the same method (signature) but not the same implementation.=20
Ecore is more about defining the API and much less about defining the =
implementation, which is typically better done in a programming language =
like Java.
Particularly if it was an abstract method in the super class this makes=20
perfect sense.
From a Java perspective. An implementation that throws an exception =
"this isn't implemented" isn't logically all that much different, other =
than the Java compile time constraints associated with it...
Subclasses that want an override could define the operation again with =
a=20
body EAnnotation and could suppress the redundant declaration from the=20
interface using another EAnnotation=20
(EcoreUtil.setSuppressedVisibility(EOperation, boolean)).
This way you'd not need specialized templates...
=20
I'll follow this up, I don't understand it but have the EMF book version =
2=20
so I'm sure this is explained in there.
Dave is very meticulous. He rarely misses a detail...
Thanks
Lionel.=20
------=_NextPart_000_0049_01C9C8B3.404F9BB0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.6000.16825" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Ed,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Unfortunately OE is being an absolute =
pain and so I=20
can't easily respond inline. I also can't remember username ans password =
so I=20
can't setup Thunderbird :(. So bear with me while I try to =
respond.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I'm not going to get into the hand =
written code=20
separation argument. Let's just say that it's a requirement of my =
project, and=20
leave it there.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV><FONT face=3DArial =
size=3D2>
<BLOCKQUOTE cite=3Dmid:gt823d$3gv$1@build.eclipse.org type=3D"cite"><PRE =
wrap=3D"">>> Particularly if it was an abstract method in the =
super class this makes=20
>> perfect sense.
</PRE></BLOCKQUOTE>
<DIV>> From a Java perspective. An implementation that throws an =
exception=20
"this isn't implemented" isn't logically all</DIV>
<DIV>> that much different, other than the Java compile time =
constraints=20
associated with it...</DIV>
<DIV> </DIV>
<DIV>But the implementation is/should be much different from that =
in my=20
case.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Anyway, I shall follow up with these annotations and see if I can =
work them=20
to do what I need.</DIV>
<DIV> </DIV>
<DIV>Thanks</DIV>
<DIV> </DIV>
<DIV>Lionel.</DIV>
<DIV></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A=20
href=3D"mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:49F78EA8.20201@gmail.com">news:49F78EA8.20201@gmail.com</A>.=
...</DIV>Bob,<BR><BR>Comments=20
below.<BR><BR>Bob wrote:=20
<BLOCKQUOTE cite=3Dmid:gt823d$3gv$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Hi Ed,
I've got to digest/understand what you are saying.
</PRE></BLOCKQUOTE>I've been accused of being like a fire hose....<BR>
<BLOCKQUOTE cite=3Dmid:gt823d$3gv$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">In the mean time some clarification, the =
reason for the modified generators=20
is to separate generated code from hand written code.
</PRE></BLOCKQUOTE>Separation of hand written and generated code seems =
to be=20
one of those "religious" types of things. Personally, I'm more =
of a=20
peanut butter cup kind of guy: if chocolate and peanut butter go good=20
together, why separate them? <BR><BR>Annotations can help by =
capturing=20
the hand written code in the model itself...<BR>
<BLOCKQUOTE cite=3Dmid:gt823d$3gv$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Some responses follow.
"Ed Merks" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:Ed.Merks@gmail.com"><Ed.Merks@gmail.com></A> wrote =
in message=20
<A class=3Dmoz-txt-link-freetext =
href=3D"news:gt6ngc$tud$1@build.eclipse.org">news:gt6ngc$tud$1@build.ecli=
pse.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Bob,
Comments below.
Bob wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi all,
I've seen some discussions on this topic but not quite what I'm after.
If I have an abstract class with abstract methods I would like to have=20
those abstract methods implemented in subclasses. However, it seems =
ecore=20
does not support abstract methods. This is not necessarily a problem, =
all=20
methods defined in the abstract class can just be generated in the=20
sub-class.
</PRE></BLOCKQUOTE><PRE wrap=3D"">EMF will always generate a stub =
implementation of the method. Of course=20
you can change it to @generated NOT and mark it as abstract instead of=20
implementing it.
</PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
Yes, in the abstract class it will, but I don't want to be editing =
generated=20
code. </PRE></BLOCKQUOTE>It goes again the religion which says: never =
the=20
twain shall meet...<BR>
<BLOCKQUOTE cite=3Dmid:gt823d$3gv$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">I'm surprised still that the model wouldn't =
provide support for=20
abstract methods, what is the reasoning behind this?
</PRE></BLOCKQUOTE>Because Ecore is a high level abstraction for =
defining=20
the API. It's not just simplified Java...<BR>
<BLOCKQUOTE cite=3Dmid:gt823d$3gv$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">
</PRE>
<BLOCKQUOTE type=3D"cite">
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">We currently have written =
some of our own JET templates to alter the code=20
generation so that methods defined in the model get generated with a =
line=20
of code that calls a static method where our custom code is:
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @model
* @generated
*/
public void abstractMethod() {
TestModel.TestModel.AbstractClassBridge.abstractMethod(this) ;
}
</PRE></BLOCKQUOTE><PRE wrap=3D"">Did you know you can specify a =
method body as an EAnnotation on the=20
EOperation? GenOperationImpl accesses it like this:
protected String getBody()
{
EOperation eOperation =3D getEcoreOperation();
EAnnotation eAnnotation =3D=20
eOperation.getEAnnotation(GenModelPackage.eNS_URI);
return eAnnotation =3D=3D null ? null :=20
(String)eAnnotation.getDetails().get("body");
}
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">So I think my ideal =
solution would be just to have this method also=20
generated in the subclasses, but by default the method isn't.
</PRE></BLOCKQUOTE><PRE wrap=3D"">If all the subclasses have the =
same method, why have copies everywhere?
</PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
They have the same method (signature) but not the same implementation.=20
</PRE></BLOCKQUOTE>Ecore is more about defining the API and much less =
about=20
defining the implementation, which is typically better done in a =
programming=20
language like Java.<BR>
<BLOCKQUOTE cite=3Dmid:gt823d$3gv$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Particularly if it was an abstract method =
in the super class this makes=20
perfect sense.
</PRE></BLOCKQUOTE>From a Java perspective. An implementation that =
throws an=20
exception "this isn't implemented" isn't logically all that much =
different,=20
other than the Java compile time constraints associated with it...<BR>
<BLOCKQUOTE cite=3Dmid:gt823d$3gv$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D""> </PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Subclasses that want an =
override could define the operation again with a=20
body EAnnotation and could suppress the redundant declaration from the=20
interface using another EAnnotation=20
(EcoreUtil.setSuppressedVisibility(EOperation, boolean)).
This way you'd not need specialized templates...
</PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
I'll follow this up, I don't understand it but have the EMF book version =
2=20
so I'm sure this is explained in there.
</PRE></BLOCKQUOTE>Dave is very meticulous. He rarely misses a=20
detail...<BR>
<BLOCKQUOTE cite=3Dmid:gt823d$3gv$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Thanks
Lionel.=20
</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0049_01C9C8B3.404F9BB0--
|
|
| |
| Re: Abstract methods [message #429704 is a reply to message #429693] |
Thu, 30 April 2009 03:14 |
Bob
Messages: 44
Registered: July 2009 |
Member |
|
|
"Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
news:gta32r$k0$1@build.eclipse.org...
> Bob wrote:
>> Ed,
>> Unfortunately OE is being an absolute pain and so I can't easily respond
>> inline. I also can't remember username ans password so I can't setup
>> Thunderbird :(. So bear with me while I try to respond.
>
> You can use your Eclipse Bugzilla account to access the newsgroups. If
> you've forgotten your Bugzilla password, you can request a reset here:
> https://bugs.eclipse.org/bugs/index.cgi?GoAheadAndLogIn=1
I only made a bugzilla account yesterday and even though I can login on the
web interface to the Eclipse Bugzilla I get an authentication error in
Thunderbird :(. My OE account is using the exquisitus username + password
but the information doesn't appear to be available anymore.
>> I'm not going to get into the hand written code separation argument.
>> Let's just say that it's a requirement of my project, and leave it there.
>
> That's for the best; I've tried before to convince Ed that not all
> projects and developers want to (or are able to) edit the EMF-generated
> code; his EMF glasses are just too dark to allow him to see that dim truth
> ;-)
I'm happy for there to be differing opinions on this matter, but there seems
to be enough demand to warrant having some support for separating manually
written code.
>> Anyway, I shall follow up with these annotations and see if I can work
>> them to do what I need.
>
> I just wanted to point out that, unless something has changed in the most
> recent versions, the EAnnotation that allows you to specify a method
> implementation in the model only works for EOperations. In most cases that
> is enough but my most recent project did find a couple of places where we
> wished we could have done it for generated property/reference getters or
> setters. Of course there is always the @generated NOT option but that gets
> back to the "religious" issue that neither you nor Ed want to talk about
> ;-)
I see your point. After having read the book I now understand what the
intention is, though I haven't got it to work with the UML diagram editor
I'm using in TopCased and I don't think it is a solution anyway. There is an
additional problem too, in the UML editor if I define an operation in an
abstract class, then define the same operation in a subclass, when I try to
reload the genmodel it complains of a duplicate method! Otherwise that would
have been a suitable hack to solve my issue :(.
Thanks for you help
Lionel.
|
|
|
| Re: Abstract methods [message #429712 is a reply to message #429704] |
Thu, 30 April 2009 10:43 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------090106040409020701050005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Bob,
Comments below.
Bob wrote:
> "Eric Rizzo" <eclipse-news@rizzoweb.com> wrote in message
> news:gta32r$k0$1@build.eclipse.org...
>
>> Bob wrote:
>>
>>> Ed,
>>> Unfortunately OE is being an absolute pain and so I can't easily respond
>>> inline. I also can't remember username ans password so I can't setup
>>> Thunderbird :(. So bear with me while I try to respond.
>>>
>> You can use your Eclipse Bugzilla account to access the newsgroups. If
>> you've forgotten your Bugzilla password, you can request a reset here:
>> https://bugs.eclipse.org/bugs/index.cgi?GoAheadAndLogIn=1
>>
>
> I only made a bugzilla account yesterday and even though I can login on the
> web interface to the Eclipse Bugzilla I get an authentication error in
> Thunderbird :(. My OE account is using the exquisitus username + password
> but the information doesn't appear to be available anymore.
>
>
>>> I'm not going to get into the hand written code separation argument.
>>> Let's just say that it's a requirement of my project, and leave it there.
>>>
>> That's for the best; I've tried before to convince Ed that not all
>> projects and developers want to (or are able to) edit the EMF-generated
>> code; his EMF glasses are just too dark to allow him to see that dim truth
>> ;-)
>>
>
> I'm happy for there to be differing opinions on this matter, but there seems
> to be enough demand to warrant having some support for separating manually
> written code.
>
What you see is what you get. The fact that what you're seeing you're
also getting for free means that demand is effectively irrelevant. Of
course I don't generally treat the community as irrelevant, but anyone
under the illusion that they can "demand" things and expect they're
simply going happen as a result is living in a dream world. Of course
I'm stating the obvious. :-P
A more interesting problem to me, because it adds power rather than
panders to what I consider a fetish (we're all entitled to opinions and
I'm doing the work) is supporting precisely the types of things that
require modifying generated code in dynamic models.
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=148992>
https://bugs.eclipse.org/bugs/show_bug.cgi?id=148992
https://bugs.eclipse.org/bugs/show_bug.cgi?id=255469
https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786
In terms of pandering to fetishes... Imagine applying the JMerge sweep
rules to a generated Java file when merging in an empty
class/interface. All that would be left would be the hand written code,
without generated code. Any file that's only an empty class/interface
could be discarded. What's left is your separate hand written code.
Run the generator against that and the result is what you get today.
The point is that it wouldn't be that hard to build some tools to manage
this, but it won't be me that's building it because I have more
important things to do.
>
>
>>> Anyway, I shall follow up with these annotations and see if I can work
>>> them to do what I need.
>>>
>> I just wanted to point out that, unless something has changed in the most
>> recent versions, the EAnnotation that allows you to specify a method
>> implementation in the model only works for EOperations. In most cases that
>> is enough but my most recent project did find a couple of places where we
>> wished we could have done it for generated property/reference getters or
>> setters. Of course there is always the @generated NOT option but that gets
>> back to the "religious" issue that neither you nor Ed want to talk about
>> ;-)
>>
>
> I see your point. After having read the book I now understand what the
> intention is, though I haven't got it to work with the UML diagram editor
> I'm using in TopCased and I don't think it is a solution anyway. There is an
> additional problem too, in the UML editor if I define an operation in an
> abstract class, then define the same operation in a subclass, when I try to
> reload the genmodel it complains of a duplicate method! Otherwise that would
> have been a suitable hack to solve my issue :(.
>
A base class and a derived class can have duplicate operations. Only a
given class can't have two exactly the same operations. I.e., exactly
the same rules as for Java should apply. There's probably something
else going on here (faulty mapping onto Ecore) that you might be
misinterpreting as a limitation on Ecore. You might consider using the
Ecore Tools graphical editor directly. It's very nice. I like it a lot.
> Thanks for you help
>
> Lionel.
>
>
>
--------------090106040409020701050005
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">
Bob,<br>
<br>
Comments below.<br>
<br>
Bob wrote:
<blockquote cite="mid:gtb52s$q5v$1@build.eclipse.org" type="cite">
<pre wrap="">"Eric Rizzo" <a class="moz-txt-link-rfc2396E" href="mailto:eclipse-news@rizzoweb.com"><eclipse-news@rizzoweb.com></a> wrote in message
<a class="moz-txt-link-freetext" href="news:gta32r$k0$1@build.eclipse.org">news:gta32r$k0$1@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Bob wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Ed,
Unfortunately OE is being an absolute pain and so I can't easily respond
inline. I also can't remember username ans password so I can't setup
Thunderbird :(. So bear with me while I try to respond.
</pre>
</blockquote>
<pre wrap="">You can use your Eclipse Bugzilla account to access the newsgroups. If
you've forgotten your Bugzilla password, you can request a reset here:
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/index.cgi?GoAheadAndLogIn=1">https://bugs.eclipse.org/bugs/index.cgi?GoAheadAndLogIn=1</a>
</pre>
</blockquote>
<pre wrap=""><!---->
I only made a bugzilla account yesterday and even though I can login on the
web interface to the Eclipse Bugzilla I get an authentication error in
Thunderbird :(. My OE account is using the exquisitus username + password
but the information doesn't appear to be available anymore.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I'm not going to get into the hand written code separation argument.
Let's just say that it's a requirement of my project, and leave it there.
</pre>
</blockquote>
<pre wrap="">That's for the best; I've tried before to convince Ed that not all
projects and developers want to (or are able to) edit the EMF-generated
code; his EMF glasses are just too dark to allow him to see that dim truth
;-)
</pre>
</blockquote>
<pre wrap=""><!---->
I'm happy for there to be differing opinions on this matter, but there seems
to be enough demand to warrant having some support for separating manually
written code.
</pre>
</blockquote>
What you see is what you get. The fact that what you're seeing you're
also getting for free means that demand is effectively irrelevant. Of
course I don't generally treat the community as irrelevant, but anyone
under the illusion that they can "demand" things and expect they're
simply going happen as a result is living in a dream world. Of course
I'm stating the obvious. :-P<br>
<br>
A more interesting problem to me, because it adds power rather than
panders to what I consider a fetish (we're all entitled to opinions and
I'm doing the work) is supporting precisely the types of things that
require modifying generated code in dynamic models.<a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=148992"><br>
</a>
<blockquote><a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=148992">https://bugs.eclipse.org/bugs/show_bug.cgi?id=148992</a><br>
<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=255469">https://bugs.eclipse.org/bugs/show_bug.cgi?id=255469</a><br>
<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786">https://bugs.eclipse.org/bugs/show_bug.cgi?id=255786</a><br>
</blockquote>
In terms of pandering to fetishes... Imagine applying the JMerge sweep
rules to a generated Java file when merging in an empty
class/interface. All that would be left would be the hand written
code, without generated code. Any file that's only an empty
class/interface could be discarded. What's left is your separate hand
written code. Run the generator against that and the result is what
you get today. The point is that it wouldn't be that hard to build
some tools to manage this, but it won't be me that's building it
because I have more important things to do.<br>
<blockquote cite="mid:gtb52s$q5v$1@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Anyway, I shall follow up with these annotations and see if I can work
them to do what I need.
</pre>
</blockquote>
<pre wrap="">I just wanted to point out that, unless something has changed in the most
recent versions, the EAnnotation that allows you to specify a method
implementation in the model only works for EOperations. In most cases that
is enough but my most recent project did find a couple of places where we
wished we could have done it for generated property/reference getters or
setters. Of course there is always the @generated NOT option but that gets
back to the "religious" issue that neither you nor Ed want to talk about
;-)
</pre>
</blockquote>
<pre wrap=""><!---->
I see your point. After having read the book I now understand what the
intention is, though I haven't got it to work with the UML diagram editor
I'm using in TopCased and I don't think it is a solution anyway. There is an
additional problem too, in the UML editor if I define an operation in an
abstract class, then define the same operation in a subclass, when I try to
reload the genmodel it complains of a duplicate method! Otherwise that would
have been a suitable hack to solve my issue :(.
</pre>
</blockquote>
A base class and a derived class can have duplicate operations. Only a
given class can't have two exactly the same operations. I.e., exactly
the same rules as for Java should apply. There's probably something
else going on here (faulty mapping onto Ecore) that you might be
misinterpreting as a limitation on Ecore. You might consider using the
Ecore Tools graphical editor directly. It's very nice. I like it a
lot.<br>
<blockquote cite="mid:gtb52s$q5v$1@build.eclipse.org" type="cite">
<pre wrap="">
Thanks for you help
Lionel.
</pre>
</blockquote>
</body>
</html>
--------------090106040409020701050005--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Abstract methods [message #429778 is a reply to message #429712] |
Fri, 01 May 2009 01:47 |
Bob
Messages: 44
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_000A_01C9CA52.89E1DEA0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Argh, OE sux.
Anyway, with reference to the below, I didn't mean demand in the sense =
of forcefully asking for it, but rather there are a lot of people who =
desire it. I understand, it's free and maybe EMF wasn't the appropriate =
choice for my project given our requirements.
There are still a lot of unanswered questions about how generated models =
should be, and can be used we are just trying to make it work for us at =
the moment and sadly there are some elements that make this difficult =
(sorry, I'm not highlighting the benefits at the moment, and there are =
some good ones).
Thanks for your help, I'll continue to search for a way to solve this =
problem.
Lionel.
"Ed Merks" <Ed.Merks@gmail.com> wrote in message =
news:gtbvce$lvp$1@build.eclipse.org...
I'm happy for there to be differing opinions on this matter, but there =
seems=20
to be enough demand to warrant having some support for separating =
manually=20
written code.
What you see is what you get. The fact that what you're seeing you're =
also getting for free means that demand is effectively irrelevant. Of =
course I don't generally treat the community as irrelevant, but anyone =
under the illusion that they can "demand" things and expect they're =
simply going happen as a result is living in a dream world. Of course =
I'm stating the obvious. :-P
------=_NextPart_000_000A_01C9CA52.89E1DEA0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.6000.16825" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Argh, OE sux.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Anyway, with reference to the below, I =
didn't mean=20
demand in the sense of forcefully asking for it, but rather there are a =
lot of=20
people who desire it. I understand, it's free and maybe EMF wasn't the=20
appropriate choice for my project given our requirements.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>There are still a lot of unanswered =
questions about=20
how generated models should be, and can be used we are just trying to =
make it=20
work for us at the moment and sadly there are some elements that make =
this=20
difficult (sorry, I'm not highlighting the benefits at the moment, and =
there are=20
some good ones).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks for your help, I'll continue to =
search for a=20
way to solve this problem.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Lionel.</FONT></DIV>
<DIV> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A=20
href=3D"mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:gtbvce$lvp$1@build.eclipse.org">news:gtbvce$lvp$1@build.ecli=
pse.org</A>...</DIV>
<BLOCKQUOTE cite=3Dmid:gtb52s$q5v$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D""><!---->
I'm happy for there to be differing opinions on this matter, but there =
seems=20
to be enough demand to warrant having some support for separating =
manually=20
written code.
</PRE></BLOCKQUOTE>
<DIV>What you see is what you get. The fact that what you're =
seeing=20
you're also getting for free means that demand is effectively=20
irrelevant. Of course I don't generally treat the community as=20
irrelevant, but anyone under the illusion that they can "demand" =
things and=20
expect they're simply going happen as a result is living in a dream =
world. Of=20
course I'm stating the obvious. :-P</DIV></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_000A_01C9CA52.89E1DEA0--
|
|
|
| Re: Abstract methods [message #429788 is a reply to message #429778] |
Fri, 01 May 2009 09:18 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------010402080403060007030805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Bob,
Comments below.
Bob wrote:
> Argh, OE sux.
>
> Anyway, with reference to the below, I didn't mean demand in the sense
> of forcefully asking for it, but rather there are a lot of people who
> desire it.
A lot would be an overstatement based on my experience. Yes there are
some, but they are by far the minority. In any case, the whole point is
that talk is cheap actions are not. Keeping them separate is not
without its drawbacks. I.e., you often end up with double the number of
classes and a stilted artificial looking hierarchy which are exactly the
kinds of things that given generators a bad name.
< http://ed-merks.blogspot.com/2008/10/hand-written-and-genera ted-code-never.html>
http://ed-merks.blogspot.com/2008/10/hand-written-and-genera ted-code-never.html
> I understand, it's free and maybe EMF wasn't the appropriate choice
> for my project given our requirements.
Maybe. Or maybe some day someone will care enough to put actions behind
their words.
>
> There are still a lot of unanswered questions about how generated
> models should be, and can be used we are just trying to make it work
> for us at the moment and sadly there are some elements that make this
> difficult (sorry, I'm not highlighting the benefits at the moment, and
> there are some good ones).
I suspect it's more of a marketing/perception/attitude problem; not
yours but I know well what it's like to deal with people who are adamant
that things simply must be a certain way even though their reasons are
flimsy at best.
>
> Thanks for your help, I'll continue to search for a way to solve this
> problem.
Note that there's even a bugzilla for this specific issue:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=181532
Some form of annotation to indicate the generated method in the Impl
should be abstract would do the trick.
Unfortunately, with 100 feature requests and two thinly stretched active
committers, not nearly as many things as I might like get done.
Now if someone actually coughed up $ to get some of the cool things they
want to see, more would get done. Of course with contributions, more
would get done and right now I have a few excellent contributions I need
to review so I can commit them. My priorities are to fix actual defects
immediately, do the cool things I think are important to get done (those
things that I believe will benefit the most people the most), process
contributions (to encourage more of them), and finally, in the
nonexistent spare time, pick over the growing 100 item long wish list
from the community.
A non-ideal solution to your problem is to produce a method with a body
that throws a not implemented exception. It doesn't give you the
immediate compile time feedback, but with proper testing, it should do
the trick almost as well...
Good luck. Sorry for the rant. It's not meant to be taken personally.
Hopefully it's good context to consider though...
>
> Lionel.
>
>
> "Ed Merks" <Ed.Merks@gmail.com <mailto:Ed.Merks@gmail.com>> wrote
> in message news:gtbvce$lvp$1@build.eclipse.org...
>>
>> I'm happy for there to be differing opinions on this matter, but there seems
>> to be enough demand to warrant having some support for separating manually
>> written code.
>>
> What you see is what you get. The fact that what you're seeing
> you're also getting for free means that demand is effectively
> irrelevant. Of course I don't generally treat the community as
> irrelevant, but anyone under the illusion that they can "demand"
> things and expect they're simply going happen as a result is
> living in a dream world. Of course I'm stating the obvious. :-P
>
--------------010402080403060007030805
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">
Bob,<br>
<br>
Comments below.<br>
<br>
Bob wrote:
<blockquote cite="mid:gtdkam$ro8$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<meta content="MSHTML 6.00.6000.16825" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">Argh, OE sux.</font></div>
<div> </div>
<div><font face="Arial" size="2">Anyway, with reference to the below,
I didn't mean demand in the sense of forcefully asking for it, but
rather there are a lot of people who desire it.</font></div>
</blockquote>
A lot would be an overstatement based on my experience. Yes there are
some, but they are by far the minority. In any case, the whole point
is that talk is cheap actions are not. Keeping them separate is not
without its drawbacks. I.e., you often end up with double the number
of classes and a stilted artificial looking hierarchy which are exactly
the kinds of things that given generators a bad name.<a
href=" http://ed-merks.blogspot.com/2008/10/hand-written-and-genera ted-code-never.html"><br>
</a>
<blockquote><a
href=" http://ed-merks.blogspot.com/2008/10/hand-written-and-genera ted-code-never.html"> http://ed-merks.blogspot.com/2008/10/hand-written-and-genera ted-code-never.html</a><br>
</blockquote>
<br>
<blockquote cite="mid:gtdkam$ro8$1@build.eclipse.org" type="cite">
<div><font face="Arial" size="2"> I understand, it's free and maybe
EMF wasn't the appropriate choice for my project given our requirements.</font></div>
</blockquote>
Maybe. Or maybe some day someone will care enough to put actions
behind their words.<br>
<blockquote cite="mid:gtdkam$ro8$1@build.eclipse.org" type="cite">
<div> </div>
<div><font face="Arial" size="2">There are still a lot of unanswered
questions about how generated models should be, and can be used we are
just trying to make it work for us at the moment and sadly there are
some elements that make this difficult (sorry, I'm not highlighting the
benefits at the moment, and there are some good ones).</font></div>
</blockquote>
I suspect it's more of a marketing/perception/attitude problem; not
yours but I know well what it's like to deal with people who are
adamant that things simply must be a certain way even though their
reasons are flimsy at best.<br>
<blockquote cite="mid:gtdkam$ro8$1@build.eclipse.org" type="cite">
<div> </div>
<div><font face="Arial" size="2">Thanks for your help, I'll continue
to search for a way to solve this problem.</font></div>
</blockquote>
Note that there's even a bugzilla for this specific issue:<br>
<blockquote><a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=181532">https://bugs.eclipse.org/bugs/show_bug.cgi?id=181532</a><br>
</blockquote>
Some form of annotation to indicate the generated method in the Impl
should be abstract would do the trick.<br>
<br>
Unfortunately, with 100 feature requests and two thinly stretched
active committers, not nearly as many things as I might like get done.<br>
<br>
Now if someone actually coughed up $ to get some of the cool things
they want to see, more would get done. Of course with contributions,
more would get done and right now I have a few excellent contributions
I need to review so I can commit them. My priorities are to fix actual
defects immediately, do the cool things I think are important to get
done (those things that I believe will benefit the most people the
most), process contributions (to encourage more of them), and finally,
in the nonexistent spare time, pick over the growing 100 item long wish
list from the community.<br>
<br>
A non-ideal solution to your problem is to produce a method with a body
that throws a not implemented exception. It doesn't give you the
immediate compile time feedback, but with proper testing, it should do
the trick almost as well...<br>
<br>
Good luck. Sorry for the rant. It's not meant to be taken
personally. Hopefully it's good context to consider though...<br>
<blockquote cite="mid:gtdkam$ro8$1@build.eclipse.org" type="cite">
<div> </div>
<div><font face="Arial" size="2">Lionel.</font></div>
<div> </div>
<blockquote dir="ltr"
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div>"Ed Merks" <<a moz-do-not-send="true"
href="mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</a>> wrote in
message <a moz-do-not-send="true"
href="news:gtbvce$lvp$1@build.eclipse.org">news:gtbvce$lvp$1@build.eclipse.org</a>...</div>
<blockquote cite="mid:gtb52s$q5v$1@build.eclipse.org" type="cite">
<pre wrap=""><!---->
I'm happy for there to be differing opinions on this matter, but there seems
to be enough demand to warrant having some support for separating manually
written code.
</pre>
</blockquote>
<div>What you see is what you get. The fact that what you're
seeing you're also getting for free means that demand is effectively
irrelevant. Of course I don't generally treat the community as
irrelevant, but anyone under the illusion that they can "demand" things
and expect they're simply going happen as a result is living in a dream
world. Of course I'm stating the obvious. :-P</div>
</blockquote>
</blockquote>
</body>
</html>
--------------010402080403060007030805--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Sat Apr 27 00:25:35 GMT 2024
Powered by FUDForum. Page generated in 0.03745 seconds |
] 
Search
Help
Register
Login
Home
