Very Cool!!!
Just solved an interesting problem for me related to different applications using the same tool. Instead of passing in multiple parameters or a super object, I can pass in the object implementing the interface to an interface parameter and reference the property via the interface rather than referencing the property through the object.
* jmls's brain explodes
I'm sorry; did I not explain that well? I can provide a code sample.
I'm sorry; did I not explain that well? I can provide
a code sample.
you may have explained it well, but I didn't get what you were trying to say
a a code sample would be great ...
Annoying part: Interface Properties cannot be implemented using a Static property. What I can't quite see is why anyone should care. Well, I can implement the object as a singleton and get almost the same effect.
Well, if you didn't get what I was saying then I didn't explain it well.
Sample coming up.
I have different, but related, applications; we'll call them office and home. Now office and home communicate with each other through Sonic. Hence, both applications run the tools/jmscomm.p procedure.
Now tools/jmscomm.p runs tools/jmsstart.p.
tools/jmsstart.p needs lots of parameters that tools/jmscomm.p doesn't have: cacheDir, sonicHost, sonicPort, userID, password, connectionParameters, etc. It needs these things regardless of who calls tools/jmscomm.
There are a number of other general application parameters which are similar in the applications and some which are different.
I had created a "static" info class of properties that the applications were going to use, but I found I needed to pass either officeinfo:cacheDir or homeinfo:cacheDir among other things to jmsstart. Now comes the fun part: how best to do it.
1) Implement jmsstart as independent procedure at the same level as jmscomm and pass data to it and pass it's result to jmscomm.
and
or other similar ways.
2) On the other hand, using Class Properties in Interfaces I can
and
{&obj}
and similarly for homeinfo.cls .
Then, I can
and
with an implementation that looks like:
Now observe that I could have done just as well with a parametrized include file, private variables and interface methods, but, as TMH likes to observe, properties were designed to fit this role.
What happened to the good ol' ini files?
They're still there. What's your point?
I am probably missing the point. I would expect two instances of the same object, where just the property values are different (typically read from an .ini file).
What am I missing?
The objects are different. They run different applications, different forms, but they use the same tools.
Yes then it makes sense.