Forums

by johnmunro >> Mon, 20 Jan 2003 10:20:38 GMT

Anyone think that it would be a good idea to ask that that isOneOf method becomes a published method?

Well, apparently Jade monitors these newsgroups, so they should already be aware that there's interest in it

John Munro

---
Synergist Limited - Home of FileVision
The Bioscience Innovation Centre
Cowley Road, Cambridge, UK
CB4 0DS

Telephone: +44 (0) 1223 478200
Fax: +44 (0) 1223 477969
Email: john.munro@filevision.com
Web: http://www.filevision.com

The contents of this communication are confidential and are only intended to be read by the addressee. We apologize if you receive this communication in error and ask that you contact Synergist Limited immediately to arrange for its return. The use of any information contained in this communication by an unauthorized person is strictly prohibited. Synergist Limited cannot accept responsibility for the accuracy or completeness of this communication as it is being transmitted over a public network. If you suspect this message may have been intercepted or amended, please inform Synergist Limited.

by cdshearer >> Mon, 20 Jan 2003 21:15:57 GMT

So, what does isOneOf actually do? And how did you find it? (We respect anonymity of sources...)

Craig

by johnmunro >> Tue, 21 Jan 2003 11:05:58 GMT

So, what does isOneOf actually do? And how did you find it? (We respect anonymity of sources...)

Basically, it returns true if the receiver is equal to any of the parameters.

To demonstrate what it does, let's look at an example. Let's say you had a method which returned a string, and if the return value was any of three values you want to do something. Normally you'd do something like this:

if getString = "one" or getString = "two" or getString = "three" then
...
endif;

The problem with this is that you are calling getString three times, and this could be a bad idea if that method is computationally expensive. If this was the case, you would probably cache the value in a variable:

vars
tmpString : String;begin

tmpString := getString;

if tmpString = "one" or tmpString = "two" or tmpString = "three" then ...
endif;
end;

There's nothing really wrong with this, but it does mean you have to create a variable, and in a large method you probably don't want to create too many of these temporary variables because it gets cluttered (and takes up memory, but it's up to you how pedantic you want to get about that).

So how would isOneOf help? Well, the code below has the exact same logical effect as the code fragments above, but without either of the drawbacks:

if getString.isOneOf("one", "two", "three") then
...
endif;

I'm afraid I'm going to have to disappoint you on the source front - no informats or spies involved - I just did a search of RootSchema for ParamListType (in an attempt to get some more information on how I might use it) and it came up with isOneOf. From the name of the method I thought it might be something like the method I was trying to create, and after some testing I decided that that's exactly what it was.

John Munro

---
Synergist Limited - Home of FileVision
The Bioscience Innovation Centre
Cowley Road, Cambridge, UK
CB4 0DS

Telephone: +44 (0) 1223 478200
Fax: +44 (0) 1223 477969
Email: john.munro@filevision.com
Web: http://www.filevision.com

The contents of this communication are confidential and are only intended to be read by the addressee. We apologize if you receive this communication in error and ask that you contact Synergist Limited immediately to arrange for its return. The use of any information contained in this communication by an unauthorized person is strictly prohibited. Synergist Limited cannot accept responsibility for the accuracy or completeness of this communication as it is being transmitted over a public network. If you suspect this message may have been intercepted or amended, please inform Synergist Limited.

by cdshearer >> Tue, 21 Jan 2003 18:58:39 GMT

Hi John

Thanks for the explanation. Looks like a useful method, and I can immediately think of some uses I have for it!

Craig

by JensRichnow >> Sat, 25 Jan 2003 7:44:32 GMT

Yes, I agree it is a useful method with many good uses. However, two comments spring immediately to my mind:

(1) It makes no sense to me that there are hidden (unpublished) methods in the first place, especially if so many of them proof useful to Jade developers in general.

(2) This point is slightly more complex. I guess one has to accept that implementation details of RootSchema methods are hidden. Coming from the Java side, it is just a beauty to look at implementation details of all methods in the standard libraries (sorry, packages ). This is a great learning curve and enables one to make an informed decision as whether to use a specific method, write a new method oneself instead or use a third party implementation. In this sense I would treat the isOneOf() method as a 'wrapper' method, as the very implementation is hidden. Potentially, and very likely, the stated drawbacks of the alternative methods given by John (computational intensive, unnecessary local variables, ...) still apply and cannot be disregarded. Going one step further, as a Jade developer one has to treat the RootSchema implementation as a black box. 'Discovering' hidden methods adds only to the size of the black box and not to the 'enlightenment' of implementation details.

by allistar >> Sat, 25 Jan 2003 8:56:52 GMT

In my 5 years of Jade development I have stumbled across quite a few "hidden" methods (either acidentally, because I hunted for them or as a tip from someone inside Cardinal). I agree that more of them should move from undocumented status to documented. (What possible dangerous side effects could there be of documenting a method like "isOneOf"?

Something that helps quite a bit is to become familiar with the meta-data structure of Jade, and learn how to iterate through RootSchema collections. You can easily find out all properties (hidden or not) on a class and all methods (hidden or not) on a Jade class.

Allowing developers to use "ParamListType" in our methods would be very handy.

Allistar.

------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz ------------------------------------------------------------------

by JensRichnow >> Sun, 26 Jan 2003 6:38:53 GMT

The phrasing "coming from the Java side" was probably misleading in that respect. In a chronical sense I would need to state "coming from the VB side and having close to five years Jade experience"---but this was not my point. I like Jade and think that I'm quit familar with Jade's meta data. I used the suggested methods, amongst others, to implement various versions of UML diagramming tools specific to Jade (with limited reverse-engineering capabilities for obvious reasons).

Actually, the phrase "coming from the Java side" was ment as a comparison to another OO language. Programming parallel in Java for a few years and developing scripting and query languages forces one to compare and think more closely about implementation details, pro's and con's. And admittedly, most of the more intricate OO programming I did not learn from the (close to) five years Jade programming but the more recent usage of Java. One might say, shame on you ... . But honestly, once you move into designing frameworks and architecture software using widely published architectural and design patterns, you realise that there are limitations in what you can do in Jade. Don't get me wrong. I really like developing with Jade. In many respects it is a rewarding feeling and experience to use Jade in RAD. I really would like to see many of the features suggested in the newsgroups implemented in the RootSchema, for many good reasons. I guess, one has to accept the path Jade is officially going and the priorities Jade has set for the near future.

With respect to the "ParamListType". If the main purpose for this is to allow to pass a list of parameters into a method, I would rather be pushing for a proper implementation of overloaded methods which more clearly reflects intention. And you see, once you ask for overloaded methods you ask for constructors similar to Java's overloaded constructors which allow to pass data for proper instantialisation of an object (I recently had the problem with the create() method in a class hierarchy whereby the run-time behaviour was not as intended and expected, as the execution of constructor methods in the inheritance cannot be controlled to the intendend extend. I ended up with a rather convoluted solution and some ugly duplications).