Hi Henrique,
That’s cool, I hadn’t considered how an enum and an interface could work
together like that. ☺
In my particular case this could work. Another idea I had is using the
EOEntity’s userInfo dictionary to store the relevant distinguishing
information. But it doesn’t seem as clean as just adding the method to the
interface, from an object-oriented / business logic encapsulation point of
view. It seemed like that capability was implied by the class comments of
EOEnterpriseObjectClazz, but perhaps it doesn’t quite go that far.
Thanks!
Mark
From: Henrique Prange <hpra...@gmail.com>
Date: Tuesday, November 20, 2018 at 8:26 PM
To: "Morris, Mark" <mark.mor...@experian.com>
Cc: "Webobjects-dev@lists.apple.com" <Webobjects-dev@lists.apple.com>
Subject: Re: EOEnterpriseObjectClazz with interface
Hey Mark,
Even if Java allowed you to override static methods of an interface, you would
still have problems to discover the classes that implement them in runtime. In
the end, it doesn't matter if you remember to implement the static method in
your subclass if you forget to call it somewhere else.
For this reason, the answer to your question must have two characteristics:
1. Subclasses of WorkflowRoutable must implement a method to provide useful
information.
2. WorkflowRoutable types must be easily discoverable at runtime.
It turns out there's a Java construct that can help you in this case. You could
create an enum of WorkflowRoutableTypes and require every subclass of
WorkflowRoutable to implement a method that returns its type.The code I imagine
looks like this:
interface WorkflowRoutable {
public static enum WorkflowRoutableType {
WORKFLOW_1 {
@Override
public String usefulInformation() {
return "useful information for workflow routable 1";
}
},
WORKFLOW_2 {
@Override
public String usefulInformation() {
return "useful information for workflow routable 2";
}
};
public abstract String usefulInformation();
}
...
/**
* Returns the type of this WorkflowRoutable. You need to create a new type
whenever
* you implement this interface. See {@code WorkflowRoutableType} for
details.
*/
WorkflowRoutableType type();
}
class Workflow1 implements WorkflowRoutable {
@Override
public WorkflowRoutableType type() {
return WorkflowRoutableType.WORKFLOW_1;
}
}
class Workflow2 implements WorkflowRoutable {
@Override
public WorkflowRoutableType type() {
return WorkflowRoutableType.WORKFLOW_2;
}
}
If you create a new Workflow3 class implementing the WorkflowRoutable
interface, the compiler will require you to override the type method. As a
result, you'll have to create a new enum type with its version of the useful
information method.
One side effect of this solution is the ability to discover WorkflowRoutable
types in runtime easily:
for (WorkflowRoutableType type : WorkflowRoutableType.values()) {
type.usefulInformation();
...
}
And then you kill two birds with one stone. ;)
Cheers,
HP
On Nov 20, 2018, at 9:50 PM, Morris, Mark
<mark.mor...@experian.com<mailto:mark.mor...@experian.com>> wrote:
Hi Johann,
Sure! Here’s a hypothetical.
Let’s say I have a WorkflowRoutable interface that defines a few instance
methods. Now I can implement that interface on EOs that need to participate in
workflow, and call those methods in my workflow processing without any trouble.
Now let’s say there’s some useful information used when configuring workflow
queues to be able to handle a particular entity, but I may not have any
instances at that point. I would want to define a class method as part of my
WorkflowRoutable interface, so that I can safely call that method to get that
entity-specific workflow information.
Again, no problem in ObjC. But static methods can’t be in Java interfaces (at
least in that way). Can the Clazz approach help with something like this?
What I do see that I could do using the EOEnterpriseObjectClazz approach is
implement the “class” method in the superclass of all my EOs with perhaps a
default implementation that returns null. Then on my entities participating in
workflow, they could override that method to return useful information. But now
*all* of my classes have that default implementation, so it’s not really a
clean workaround….
Thanks again!
Mark
From: Johann Werner <johann.wer...@posteo.de<mailto:johann.wer...@posteo.de>>
Date: Tuesday, November 20, 2018 at 3:39 AM
To: "Morris, Mark" <mark.mor...@experian.com<mailto:mark.mor...@experian.com>>
Cc: "Webobjects-dev@lists.apple.com<mailto:Webobjects-dev@lists.apple.com>"
<Webobjects-dev@lists.apple.com<mailto:Webobjects-dev@lists.apple.com>>
Subject: Re: EOEnterpriseObjectClazz with interface
Hi Mark,
I think you have to tell us what exactly you want to achieve? Do you have an
example?
With the EOEnterpriseObjectClazz you have a static instance within your class
but this instance is… an instance so you could put an „implements interface“ on
it. Or if you just want to know if class A has a static clazz object you could
create some empty interface (IHasClazzObject) as marker.
jw
Am 19.11.2018 um 22:12 schrieb Morris, Mark
<mark.mor...@experian.com<mailto:mark.mor...@experian.com>>:
Hallo Johann,
Thanks for the info. I do see how I could create a default implementation of
the “static” method I’m expecting in our local EO superclass’s util inner
class, and from then on know that it will be legal to call it from any of our
subclasses. So that could work in this case.
In general though I still don’t see how, or if it’s even possible, to do what I
was originally trying with the interface. For instance methods, I can just test
“myClass instanceof myInterface” and know whether that class implements the
methods. In ObjC, I could do the same with a protocol, but with instance and
class methods. It seems like the description of the clazz paradigm is saying it
makes that possible, but I’m just not understanding how that works.
Thanks again. Tschüß!
Mark
From: Johann Werner <johann.wer...@posteo.de<mailto:johann.wer...@posteo.de>>
Date: Monday, November 19, 2018 at 1:37 AM
To: "Morris, Mark" <mark.mor...@experian.com<mailto:mark.mor...@experian.com>>
Cc: "Webobjects-dev@lists.apple.com<mailto:Webobjects-dev@lists.apple.com>"
<Webobjects-dev@lists.apple.com<mailto:Webobjects-dev@lists.apple.com>>
Subject: Re: EOEnterpriseObjectClazz with interface
Hi Mark,
have a look at BugTracker and its dependent framework BTBusinessLogic. That
should you give some ideas. There are some more apps/frameworks in Wonder using
that pattern, just have a look at the type hierarchy of the
EOEnterpriseObjectClazz class (in Eclipse right click on the class name and
select „Open Type Hierarchy“ from the context menu).
jw
Am 19.11.2018 um 06:31 schrieb Morris, Mark
<mark.mor...@experian.com<mailto:mark.mor...@experian.com>>:
Hi all,
I ran into a simple case where a good old ObjC protocol would have worked fine,
but Java provides only frustration. 😉
I wanted to require that a class that decides to implement a particular
interface should as part of that interface implement a certain static method.
No go in Java.
The implementing classes will always be subclasses of ERXGenericRecord, and a
little searching uncovered the promising EOEnterpriseObjectsClazz approach.
Right at the top it says:
In Java, static methods are similar to class methods in Objective-C, but one
cannot use static methods in interfaces and static methods cannot be overridden
by a subclass. Using the clazz pattern removes those limitations.
However, I didn’t see any examples of this use, and spent a little time but
couldn’t figure it out. Are there any examples out there?
Thanks!
Mark
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list
(Webobjects-dev@lists.apple.com<mailto:Webobjects-dev@lists.apple.com>)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/hprange%40gmail.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apple.com_mailman_options_webobjects-2Ddev_hprange-2540gmail.com&d=DwMFaQ&c=BNNF-YNv0CLLslhP2Bcx5Q&r=R0ZqsewJs3eSJk7vLCqZv0r5kJlLXQLnGTeg9t8MlqA&m=o8-RNjfQ9AJpG6vpya-NIWz1Lhz4ci4OUDA91WrxhY8&s=kTd6xncZdrN8Awozd5MC2WFMJ0QUEKSkKVcXQ7Sppg8&e=>
This email sent to hpra...@gmail.com<mailto:hpra...@gmail.com>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
