Xojo Conferences
XDCMay2019MiamiUSA

Re: class extensions ... (Real Studio Plugins Mailinglist archive)

Back to the thread list
Previous thread: Re: Correct wat to Draw strings
Next thread: DX midi plugin back in town?


Re: FSRef support in plugin API   -   Thomas Tempelmann
  Re: class extensions ...   -   François Menneteau <
    Re: class extensions...   -   Paul Mitchum
     Re: class extensions...   -   Joseph J. Strout
      Re: class extensions...   -   Paul Mitchum
      Re: class extensions...   -   Christian Schmitz
       Re: class extensions...   -   Joseph J. Strout
      Re: class extensions...   -   Jan Erik Moström <
       Re: FSRef support in plugin API   -   Thomas Tempelmann
    Re: class extensions...   -   Mars Saxman

Re: class extensions ...
Date: 06.06.02 11:53 (Thu, 06 Jun 2002 12:53:15 +0200)
From: François Menneteau <
>
> >Fortunately, I have extended only the graphic class.
>
> OK. Then I would recommend you put in a request with REALbugs to
> make the Graphics class usefully subclassable (and explain why).

Oh, I just remembered that I have extended the MemoryBlock class too :-)

Re: class extensions...
Date: 06.06.02 18:40 (Thu, 06 Jun 2002 10:40:26 -0700)
From: Paul Mitchum
On 6/6/02 7:32 AM, "Joseph J. Strout" <<email address removed>> wrote:

> At 12:46 PM +0200 6/6/02, Christian Schmitz wrote:
>
>> I just want to add that my MBS Plugin which is currently built from 31
>> small plugins has 7 folderitem Extensions and 4 memoryblock
>> extensions...
>>
>> What should I do? Make 7 subclasses of folderitems?
>
> No, one subclass of FolderItems. If somebody adds the "MBS Plugin"
> (really plugins) to their plugins folder, they get the functionality
> of all 7 in one place, so you might as well put them all in one place
> too. And one memoryblock subclass.

This is fine if I only ever want to do something MBS can do with a given
folderitem subclass object. Will the new compiler have easy coercion?
Something like:

(MBSFolderItem)folderitemreference.MBSmethod

And what's the fate of XCMDs, anyway? Keepin 'em?

Re: class extensions...
Date: 06.06.02 18:45 (Thu, 6 Jun 2002 10:45:46 -0700)
From: Joseph J. Strout
At 10:40 AM -0700 6/6/02, Paul Mitchum wrote:

>This is fine if I only ever want to do something MBS can do with a given
>folderitem subclass object. Will the new compiler have easy coercion?
>Something like:
>
>(MBSFolderItem)folderitemreference.MBSmethod

No, you'd have to do something more like

(New MBSFolderItem(folderitemreferenc)).MBSmethod

However, one thing the new compiler may (MAY! no promises here!) have
is namespaces. So, in cases where currently you have very many
extensions of a particular class, if a subclass doesn't work, then
global methods in a namespace might work instead. That would look
like this:

MBSFileUtils.MBSmethod(folderItemReference)

>And what's the fate of XCMDs, anyway? Keepin 'em?

Hmm, difficult to see. Always in motion is the future...

Cheers,
- Joe

Re: class extensions...
Date: 06.06.02 19:14 (Thu, 06 Jun 2002 11:14:43 -0700)
From: Paul Mitchum
On 6/6/02 10:45 AM, "Joseph J. Strout" <<email address removed>> wrote:

> At 10:40 AM -0700 6/6/02, Paul Mitchum wrote:
>
>> (MBSFolderItem)folderitemreference.MBSmethod
>
> No, you'd have to do something more like
>
> (New MBSFolderItem(folderitemreferenc)).MBSmethod

That's what I get for typing sample code before my first cup of coffee.

> However, one thing the new compiler may (MAY! no promises here!) have
> is namespaces. So, in cases where currently you have very many
> extensions of a particular class, if a subclass doesn't work, then
> global methods in a namespace might work instead. That would look
> like this:
>
> MBSFileUtils.MBSmethod(folderItemReference)

This looks good, as long as we don't end up with namespaces like 'FileStuff'
or 'MyPlugin.'

>> And what's the fate of XCMDs, anyway? Keepin 'em?
>
> Hmm, difficult to see. Always in motion is the future...

HyperYoda.

Re: class extensions...
Date: 06.06.02 19:32 (Thu, 6 Jun 2002 20:32:42 +0200)
From: Christian Schmitz
> At 10:40 AM -0700 6/6/02, Paul Mitchum wrote:
>
> However, one thing the new compiler may (MAY! no promises here!) have
> is namespaces....

Nothing we need if you find a way for class extensions...

And you have still a lot of time till than.
(maybe RB 6?)

Mfg
Christian

Re: class extensions...
Date: 06.06.02 21:34 (Thu, 6 Jun 2002 13:34:06 -0700)
From: Joseph J. Strout
At 8:32 PM +0200 6/6/02, Christian Schmitz wrote:

> > However, one thing the new compiler may (MAY! no promises here!) have
>> is namespaces....
>
>Nothing we need if you find a way for class extensions...

No, I disagree strongly with that. Class extensions are a convenient
hack, but namespaces are a very elegant way of managing organizing a
large number of identifiers. That's true quite regardless of class
extensions.

Best,
- Joe

Re: class extensions...
Date: 23.03.01 11:20 (Thu, 6 Jun 2002 20:34:18 +0200)
From: Jan Erik Moström <
2002-06-06 10:45: Joseph J. Strout <<email address removed>> is believed to
have typed:

> However, one thing the new compiler may (MAY! no promises here!) have
> is namespaces.

Yes, yes, yes ... but if you decide to implement them please make them
more like Javas packages than C++ namespaces.

jem

Re: class extensions...
Date: 06.06.02 23:36 (Thu, 06 Jun 2002 15:36:36 -0700)
From: Mars Saxman
<email address removed> wrote:

> Of course all this can be done in C++ (except the "none" modifier) but
> it feels much more robust in Java. In general I would say that REALbasic
> should be closer to Java than to C++ ... it would make it easier for
> beginners (and experts) to avoid making mistakes.

Thanks for your comments - it's useful to know what sort of features people
are looking for from namespaces or packages. I hope we will get the
opportunity to add such a feature to RB.

Mars Saxman
REAL Software

- - - - - - - - - -
For list commands, send "Help" in the body of a message to
<<email address removed>>
Unsubscribe:
<mailto:<email address removed>>