Problem with porting current system - Forum - OpenEdge Development - Progress Community

Problem with porting current system

 Forum

Problem with porting current system

  • If I understood his converns:

    IF SomeObject:getClass():TypeName EQ "myapp.library.sessionsingleton" THEN

    this issues appears at runtime. As soon as a .NET class is loaded, the SomeObject:getClass():TypeName can fail (when walking the SESSION:FIRST-OBJECT chain) because getClass() does not return a class reference when run for .NET objects.

  • OK, so the problem is both development and production and as long as one is going to have the potential for .NET objects in the session ... which is rather the point, then the options are to check for a valid object first or use TYPE-OF. Right?

    I would think that it should be a fairly straightforward refactoring to change

    SomeObject:getClass():TypeName EQ "myapp.library.sessionsingleton"

    into

    TYPE-OF(SomeObject, myapp.library.sessionsingleton)

    Mind you, I can see why Julian is grumbling, but the reasons seem valid, the workaround doesn't seem too difficult, and the new construct is not objectionable in form.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • I'm not sure that I have followed all of this

    exactly, so can I ask for a clarification, Julian?

    Sure thing.

    In earlier versions, it was common to RUN code in OEA

    using the same AVM which one was using to parse,

    syntax check, etc. While keeping down the number of

    AVMs running, this has some obvious issues, e.g.,

    things which didn't get cleaned up from earlier

    activities because the session didn't terminate in

    the way it would had we been doing the RUN in a

    separate AVM.

    True. However, I am still trying to wean myself off pressing the procedure editor button, and typing "run startup.p"

    So, now we have shifted best practice in OEA such

    that we are starting a separate AVM for a RUN. No?

    While this can mean that one ends up with extra hung

    AVMs needing to be cleaned up, it means that one can

    have several configurations available for testing at

    any time. Yes?

    Yes. And a very very nice feature it is too. Thanks !

    Are you saying that, if you follow current best

    practice and run code which has no .NET references,

    that you are having the problem?

    If there is no .net, everything works just peachy.

    >Or is it that you

    run code which now has .NET references in the session

    and you are having a problem with code which used to

    work no longer working because there are .NET

    entities in the class tree?

    Yes.

    If the latter, which is my best guess at the moment,

    would I be correct that this will be a problem in

    production, not just in development?

    Yes.

    >That would seem

    to be true if it were the presence of a .NET class

    anywhere in the session. Or, are you saying that it

    only happens in the context of OEA?

    No - it's if there is any .net object present in the session, regardless of OEA

  • If I understood his converns:

    IF SomeObject:getClass():TypeName EQ

    "myapp.library.sessionsingleton" THEN

    this issues appears at runtime. As soon as a .NET

    class is loaded, the SomeObject:getClass():TypeName

    can fail (when walking the SESSION:FIRST-OBJECT

    chain) because getClass() does not return a class

    reference when run for .NET objects.

    Yes - that's the problem.

  • OK, so the problem is both development and

    production and as long as one is going to have the

    potential for .NET objects in the session ... which

    is rather the point, then the options are to check

    for a valid object first or use TYPE-OF. Right?

    Right.

    I would think that it should be a fairly

    straightforward refactoring to change

    SomeObject:getClass():TypeName EQ

    "myapp.library.sessionsingleton"

    into

    TYPE-OF(SomeObject, myapp.library.sessionsingleton)

    It was See my earlier posts. I was just grumbling that I had to change my code to move my app into 10.2A. I'm just a bitter old man that wants to run his v3 code unchanged ...

    Mind you, I can see why Julian is grumbling, but the

    reasons seem valid, the workaround doesn't seem too

    difficult, and the new construct is not objectionable

    in form.

    All absolutely true.

  • I was just grumbling that I had to change my code to move my app into 10.2A.

    Well, if you didn't want to use the new features, you could! No different than those times in the past when one discovered that one had made the mistake of using a field name which turned into a reserved word in a later release. One could always use the keyword forget list to keep going, but then one couldn't use the new feature.

    I'm just a bitter old man that wants to run his v3 code unchanged ...

    I suspect there's no contest around here who is more of an old man ... but, the really amazing thing about ABL is the extent to which that V3 code still does run. In fact, it is only last week or so that I was educating someone on ProgressTalk about why solving a problem with an editing clause wasn't really the best idea ... he was just copying what he saw everywhere else in his application and was tickled pink to know the answer to someone else's question. When I think what has happened to this language between 1984 when I first discovered it and now, it is staggering and yet how rarely I have had to make a change because of a version shift and when I did it was quite minor.

    More likely you are closer to being spoiled than bitter!

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Well, if you didn't want to use the new features, you

    could!

    Yeah, that point was already conceded.

    I suspect there's no contest around here who is more

    of an old man ... but, the really amazing thing about

    ABL is the extent to which that V3 code still does

    run.

    It's pretty damned amazing. However, I hate to think of the amount of "spaghetti code" that must be lying around supporting all the old v3+ stuff and the poor sod that has to maintain it. It's hard enough for me to maintain my own code from 5 years ago. not some other programmer's from 20 years ago !

    More likely you are closer to being spoiled than

    bitter

    Definitely spoiled.

  • I hate to think of the amount of "spaghetti code" that must be lying around supporting all the old v3+ stuff and the poor sod that has to maintain it.

    Well, as evidenced by that fellow on ProgressTalk, in many cases they don't know any better. They get the job, quite possibly learn the language on the job, look at their own application for examples, and just keep trundling along. Depending on how much they read, they might realize that they are in something of a backwater, but I suspect many of them don't feel the pain the way we would because they really don't know any better. Moreover, even if they do have some perception of being in a backwater, they probably think of it in terms of other languages, not realizing that they are in a terrible backwater with respect to ABL itself.

    Of course, the flip side is that it makes a lot of transformation candidates to be my prospect base!

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Well, as evidenced by that fellow on ProgressTalk, in

    many cases they don't know any better. They get the

    job, quite possibly learn the language on the job,

    look at their own application for examples, and just

    keep trundling along.

    Sorry, I meant the "c" code for the ABL itself .

  • I suspect that the underlying code has had considerably more architectural revision than many of the ABL systems and that it isn't nearly as horrible. This is not to say that there aren't some dinosaurs wandering around in there.

    Of course, some of reasons for some of those dinosaurs is exactly the upward compatibility we have enjoyed on the outside. Think how often someone has thought that there were all these places which were doing something similar which could be brought together into common code, but they were quite orthogonal so it was hard to combine and maintain that compatibility. Painful.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com