On Sat, Dec 13, 2008 at 1:24 PM, Rick McGuire <object.rexx@...> wrote:
> There's only one init method, which is normally called by the new
> method of the class object. The normal pattern if you wish to have
> multiple versions of "new" is to have the additional class methods
> call new, then perform any additional initialization after new
> completes. For example, .array~of essentially does
>
> newarray = self~new(arg())
> do item over arg(1, 'a')
> newarray~append(item)
> end
>
> So to implement what you wish to do, you'd have the init method do a
> minimal setup, then have the additional method call any additional
> methods needed to complete the set up.
Thanks Rick.
That's pretty much what I came up with. I was having a hard time
seeing what the minimal set up would be. But, that worked itself out
when I realized I really should hae two different classes for what I
was doing.
--
Mark Miesfeld

There's only one init method, which is normally called by the new
method of the class object. The normal pattern if you wish to have
multiple versions of "new" is to have the additional class methods
call new, then perform any additional initialization after new
completes. For example, .array~of essentially does
newarray = self~new(arg())
do item over arg(1, 'a')
newarray~append(item)
end
So to implement what you wish to do, you'd have the init method do a
minimal setup, then have the additional method call any additional
methods needed to complete the set up.
Rick
On Sat, Dec 13, 2008 at 11:10 AM, Mark Miesfeld <miesfeld@...> wrote:
> What would be the proper way to implement something like:
>
> a = .array~new
> b = .array~of(1, 2, 3,)
>
> using the native API for a new class?
>
> In other words, I want to define a new class where there are several
> different *sets* of initialization options that can be used to create
> the new object. Rather than define one init() method with a bunch of
> OPTIONAL_RexxObjectPtr and go through a lot of contortions to figure
> out which set of initialization options is being used, I'd like to
> something like:
>
> RexxMethodn(RexxObjectPtr, myclass_new, CSTRING, x, RexxStringObject,
> y, int, z, OPTIONAL_uint8_t)
> RexxMethodn(RexxObjectPtr, myclass_new_of, POINTER, p uint32_t, t,
> POINTER p1, CSTRING, c, CSTRING, d)
> RexxMethodn(RexxObjectPtr, myclass_new_load, ....
>
> Can that be done?
>
> I'm a little hazy on how to approach this / what needs to be done.
> Maybe, create a no arg init() method, and in myclass_new_of send a
> 'new' message to OSELF ... I know that's not what <grin> Just
> putting it out to show that I'm unsure of how to do this.
>
> I'd like the default 'new' to be the easiest to use, but it still
> needs args. That is simple enough, change myclass_new above to
>
> RexxMethodn(RexxObjectPtr, myclass_init, CSTRING, x, RexxStringObject,
> y, int, z, OPTIONAL_uint8_t)
>
> But, I can't see how to implement the myclass_new_of and myclass_new_load.
>
> --
> Mark Miesfeld
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you. Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@...
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>

What would be the proper way to implement something like:
a = .array~new
b = .array~of(1, 2, 3,)
using the native API for a new class?
In other words, I want to define a new class where there are several
different *sets* of initialization options that can be used to create
the new object. Rather than define one init() method with a bunch of
OPTIONAL_RexxObjectPtr and go through a lot of contortions to figure
out which set of initialization options is being used, I'd like to
something like:
RexxMethodn(RexxObjectPtr, myclass_new, CSTRING, x, RexxStringObject,
y, int, z, OPTIONAL_uint8_t)
RexxMethodn(RexxObjectPtr, myclass_new_of, POINTER, p uint32_t, t,
POINTER p1, CSTRING, c, CSTRING, d)
RexxMethodn(RexxObjectPtr, myclass_new_load, ....
Can that be done?
I'm a little hazy on how to approach this / what needs to be done.
Maybe, create a no arg init() method, and in myclass_new_of send a
'new' message to OSELF ... I know that's not what <grin> Just
putting it out to show that I'm unsure of how to do this.
I'd like the default 'new' to be the easiest to use, but it still
needs args. That is simple enough, change myclass_new above to
RexxMethodn(RexxObjectPtr, myclass_init, CSTRING, x, RexxStringObject,
y, int, z, OPTIONAL_uint8_t)
But, I can't see how to implement the myclass_new_of and myclass_new_load.
--
Mark Miesfeld

Hi Mark,
well I was in the middle of composing that tracker item when I found
that I didn't know what I was talking about. I shall now go ahead and
recompose and submit it.
thanks for this and all your work on ooDialog. It is very impressive!
Jon
2008/12/13 Mark Miesfeld <miesfeld@...>:
> On Sat, Dec 13, 2008 at 1:37 AM, Sahananda (Jon) Wolfers
> <sahananda@...> wrote:
>
>> This is what I think is the case:
>> 1) what used to be described as ooDialog external functions still
>> exist and are callable in 4.0.0 with the exception of instMMfuncs
>
> Everything that was documented in 3.2.0, should work in 4.0.0.
>
>> 2) You no longer need to load them - you can just call them - hence
>> the loss of instMMfuncs
>
> The user, (the ooRexx programmer,) no longer explicitly registers
> external functions. The 4.0.0 native APIs do that implicitly, and in
> a much more stable way.
>
> In the ooDialog framework, in my opinion, it was never meant for the
> user to register the external functions. The framework took care of
> that. Once you instantiated a dialog, the external functions were
> registered.
>
> But, there was the inconvenient fact that some people wanted to just
> the message box functions, without creating a dialog. To do that some
> of the external functions needed to be registered.
>
> In hindsight, I wish they hadn' documented that. All of the
> documented external functions have a corresponding public routine that
> does not require the user to explicitly register an external function.
> Then, instead of having a dummy instMMFuncs() that does nothing, we
> could just drop that function altogether.
>
>> 3) There are equivalent public routines for most/all of them, just
>> named slightly differently
>> Is that correct?
>
> Yes, that is correct. It would have been better if the doc and just
> pointed the user to those public routines and left out the external
> functions altogether.
>
>> Section 10.2 of the ooDIalog manual still tells one that one may need
>> to call instMMfuncs (revision 3794)
>
> The ooDialog reference still needs a huge amount of updating. When /
> if you see things like this in the doc, you could help by opening up a
> tracker documentation item for it. Some items are already open. This
> would help us be sure we don't forget something. (Well, really that I
> don't forget something.)
>
> --
> Mark Miesfeld
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you. Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@...
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>

On Sat, Dec 13, 2008 at 1:37 AM, Sahananda (Jon) Wolfers
<sahananda@...> wrote:
> This is what I think is the case:
> 1) what used to be described as ooDialog external functions still
> exist and are callable in 4.0.0 with the exception of instMMfuncs
Everything that was documented in 3.2.0, should work in 4.0.0.
> 2) You no longer need to load them - you can just call them - hence
> the loss of instMMfuncs
The user, (the ooRexx programmer,) no longer explicitly registers
external functions. The 4.0.0 native APIs do that implicitly, and in
a much more stable way.
In the ooDialog framework, in my opinion, it was never meant for the
user to register the external functions. The framework took care of
that. Once you instantiated a dialog, the external functions were
registered.
But, there was the inconvenient fact that some people wanted to just
the message box functions, without creating a dialog. To do that some
of the external functions needed to be registered.
In hindsight, I wish they hadn' documented that. All of the
documented external functions have a corresponding public routine that
does not require the user to explicitly register an external function.
Then, instead of having a dummy instMMFuncs() that does nothing, we
could just drop that function altogether.
> 3) There are equivalent public routines for most/all of them, just
> named slightly differently
> Is that correct?
Yes, that is correct. It would have been better if the doc and just
pointed the user to those public routines and left out the external
functions altogether.
> Section 10.2 of the ooDIalog manual still tells one that one may need
> to call instMMfuncs (revision 3794)
The ooDialog reference still needs a huge amount of updating. When /
if you see things like this in the doc, you could help by opening up a
tracker documentation item for it. Some items are already open. This
would help us be sure we don't forget something. (Well, really that I
don't forget something.)
--
Mark Miesfeld

OK,
my last reply has demonstrated that I don't understand what is going on here.
This is what I think is the case:
1) what used to be described as ooDialog external functions still
exist and are callable in 4.0.0 with the exception of instMMfuncs
2) You no longer need to load them - you can just call them - hence
the loss of instMMfuncs
3) There are equivalent public routines for most/all of them, just
named slightly differently
Is that correct?
Section 10.2 of the ooDIalog manual still tells one that one may need
to call instMMfuncs (revision 3794)
thanks,
Jon
2008/12/12 Sahananda (Jon) Wolfers <sahananda@...>:
> 2008/12/12 Mark Miesfeld <miesfeld@...>:
>> On Fri, Dec 12, 2008 at 10:24 AM, Sahananda (Jon) Wolfers
>> <sahananda@...> wrote:
>>
> ...snip...
>>> but even when I correct that I cant load instMMFuncs.
>>
>> You shouldn't be calling that function, it doesn't exist in 4.0.0.
>> Arrgh, I didn't realize that function had been documented. I'll have
>> to put the dummy back in. ;-(
>>
>> In 4.0.0 all that
>>
>> call RxFuncAdd InstMMFuncs, "oodialog", InstMMFuncs
>> call InstMMFuncs
>>
>> stuff is done away with. As I said, I'll put the dummy back in, but
>> it does absolutely nothing.
>>
>> I would really like to get rid of all the unneeded baggage in
>> ooDialog. So, I'm taking the attitude that if something was
>> undocumented, then no one should rely on it being there.
>>
>> --
>> Mark Miesfeld
>
> Interesting. Good move replacing all the functions with ::routines -
> nice work. I see that that is already the case in 3.2.0 so I should
> be able to just do away with my rxfuncadd now.
>
> Jon
>