In some dev work here, I've come across a need for getting the file name (ie actual file that was run) for a type. So given Foo.Bar.Baz I need Foo/Bar/Baz.cls (or .r, depending). To do this I need to do some REPLACE() and appending, which is, basically, yuk.
I would basically like to be able to do something like:
oType = get-class(Foo.Bar.Baz).
hRcode = oType:RcodeInfo.
(I could like with cFile = oType:FileName).
My use-case for this is taking parameters passed in text form (config file and/or param) and finding the rcode for that type.
Does anyone have any other use-cases for this kind of functionality, or feel that it'd be useful for their apps?
-- peter
There isn't a lot to computing these themes and variations and search() will tell you the actual file name which would be used. The problem I see with making these built-ins is that one would have to already have an instance to get the information. I can certainly see this as being useful in debugging and logging, but less so in tools.
Peter suggested the feature as a property of Progress.Lang.Class (leaking some syntax I haven't seen yet).
So for Progress.Lang.Class you don't need an object instance.
Err, but if there a 5 different versions of a class, which one would it tell you. Seems like you would need an instance to have resolved the search. Otherwise, isn't search the right tool?
Can you clarify what you mean with 5 different versions of a class?
Each type is uniquely identified by a type name.
Are you talking about different Foo.SubFoo.FooClass in different PROPATH entries? That's hell on earth and worse - believe me.
There isn't a lot to computing these themes and variations and search() will tell you the actual file name which would be used. The problem I see with making these built-ins is that one would have to already have an instance to get the information. I can certainly see this as being useful in debugging and logging, but less so in tools.
Yes, I am talking exactly about different propath versions. 5 might be pushing things a bit, but it was common for me in development to have my current version, a customer specific version, and the base released version of something.
Yes, I am talking exactly about different propath versions. 5 might be pushing things a bit, but it was common for me in development to have my current version, a customer specific version, and the base released version of something.
[quote user="Thomas Mercer-Hursh"]
Yes, I am talking exactly about different propath versions. 5 might be pushing things a bit, but it was common for me in development to have my current version, a customer specific version, and the base released version of something.
[/quote]
I highly recommend to give up that habbit for OO code. Period. One classname, one R-Code available.
Mike and I agree again ! this is getting spooky ;)
Julian
On 6 January 2014 20:56, Mike Fechner
wrote:
> Thomas Mercer-Hursh
>
> Yes, I am talking exactly about different propath versions. 5 might be
> pushing things a bit, but it was common for me in development to have my
> current version, a customer specific version, and the base released version
> of something.
>
> I highly recommend to give up that habbit for OO code. Period. One
> classname, one R-Code available.
>
>
[quote user="jmls"]Mike and I agree again ! this is getting spooky ;)
[/quote]
:-)
Of course, with MBD I *have* given it up, but it *is* a common way that ISVs handle the problem of having a released version, components under test, and possibly customer-specific code.
I have met lots of ISV's recently. But no one adopted this insane property for OO code - and that's what this thread is about.
It's the millenium of SCM tools to handle different versions.