Xojo Conferences
XDCMay2019MiamiUSA

FSRef support in plugin API (Real Studio Plugins Mailinglist archive)

Back to the thread list
Previous thread: class extensions (was Re: FSRef support in plugin API)
Next thread: How to call PC BIOS functions


Re: class extensions...   -   Jan Erik Moström <
  FSRef support in plugin API   -   Joseph J. Strout
   Re: FSRef support in plugin API   -   Christian Schmitz
    Re: FSRef support in plugin API   -   Joseph J. Strout
   Re: FSRef support in plugin API   -   Paul Mitchum
   Re: FSRef support in plugin API   -   Alfred Van Hoek
    Re: FSRef support in plugin API   -   François Menneteau <
   Re: FSRef support in plugin API   -   Chad J McQuinn
    Re: FSRef support in plugin API   -   Joseph J. Strout
     Re: FSRef support in plugin API   -   Chad J McQuinn
      Re: FSRef support in plugin API   -   Christian Schmitz
       Re: FSRef support in plugin API   -   Chad J McQuinn
    Re: FSRef support in plugin API   -   Thomas Tempelmann
     Re: FSRef support in plugin API   -   Will Cosgrove
      Re: FSRef support in plugin API   -   Joseph J. Strout
       Re: FSRef support in plugin API   -   Will Cosgrove
        Re: FSRef support in plugin API   -   Joseph J. Strout
    Re: FSRef support in plugin API   -   Thomas Tempelmann
    Re: FSRef support in plugin API   -   Thomas Tempelmann
     Re: FSRef support in plugin API   -   François Menneteau <
     Re: FSRef support in plugin API   -   Joseph J. Strout
      Re: FSRef support in plugin API   -   Christian Schmitz
       Re: FSRef support in plugin API   -   Mars Saxman
        Re: FSRef support in plugin API   -   Christian Schmitz
         Re: FSRef support in plugin API   -   Paul Mitchum
          Re: FSRef support in plugin API   -   Joseph J. Strout
           Re: FSRef support in plugin API   -   Paul Mitchum
           Re: FSRef support in plugin API   -   Einhugur Software
     Re: FSRef support in plugin API   -   François Menneteau <
     Re: class extensions ...   -   François Menneteau <
    Re: FSRef support in plugin API   -   Thomas Tempelmann
     Re: FSRef support in plugin API   -   Alfred Van Hoek
    Re: FSRef support in plugin API   -   Thomas Tempelmann
     Re: FSRef support in plugin API   -   Christian Schmitz
      Re: FSRef support in plugin API   -   Joseph J. Strout
       Re: FSRef support in plugin API   -   Christian Schmitz
       Re: class extensions...   -   Paul Mitchum

FSRef support in plugin API
Date: 04.06.02 23:08 (Tue, 4 Jun 2002 15:08:08 -0700)
From: Joseph J. Strout
Hi gang,

I'm currently working on the plugin API. One thing some plugin
authors have asked for are access to FSRefs to and from FolderItems.
But this turns out to be rather tricky to support much better than
it's supported already.

If the FolderItem in question refers to a file that already exists,
then the existing APIs suffice -- you can convert an FSRef to/from an
FSSpec by using FSpMakeFSRef and FSGetCatalogInfo.

But if you want to refer to a file that doesn't exist, then this is
much harder. In general you have to use something like the FSRef of
the parent, plus the name of the file you have in mind. But this
pattern doesn't work for the root directory of a volume (which has no
parent).

So, I'm wondering if anybody has a pressing need to pass references
to files that don't exist to/from a plugin, and what the details of
that need are. Perhaps that will let us come up with an API that
hides as much of this unpleasantness as possible.

Best,
- Joe

Re: FSRef support in plugin API
Date: 04.06.02 23:33 (Wed, 5 Jun 2002 00:33:33 +0200)
From: Christian Schmitz
> Hi gang,
>
> So, I'm wondering if anybody has a pressing need to pass references
> to files that don't exist to/from a plugin, and what the details of
> that need are.

Sure. The function to create a Largebinarystream needs a folderitem for
the target file and this not yet present. But there I won't need FSRef.

I think you might add just some utility stuff to the API to give us a
default way to get a FSRef from a Folderitem.
No change in the Calls to RBRuntime, but some more functions in the API
itself. (which internally does what you said above)

PS: If you add API stuff, please add accessors to all the handels of the
classes, so we can use them as parameters to ours.

Also a REALBuildString with a parameter to tell RB the encoding would be
nice and a function to ask which encoding a string has and a way to
convert a string to ASCII or ANSI so we won't need our own encoding
stuff in every plugin.

Mfg
Christian

Re: FSRef support in plugin API
Date: 04.06.02 23:49 (Tue, 4 Jun 2002 15:49:22 -0700)
From: Joseph J. Strout
At 12:33 AM +0200 6/5/02, Christian Schmitz wrote:

> > So, I'm wondering if anybody has a pressing need to pass references
>> to files that don't exist to/from a plugin, and what the details of
>> that need are.
>
>Sure. The function to create a Largebinarystream needs a folderitem for
>the target file and this not yet present. But there I won't need FSRef.

OK -- I'm not sure what you're referring to here, I assume it's one
of your functions. It sounds like you DO need an FSRef though; you
can't properly create a file in OS X without it (what if the file
name is longer than 31 characters, for example)?

>I think you might add just some utility stuff to the API to give us a
>default way to get a FSRef from a Folderitem.

Well, that's the whole issue I'm trying to work out.

>No change in the Calls to RBRuntime, but some more functions in the API
>itself. (which internally does what you said above)

No, without more calls to the runtime, it can't be done. For files
that do exist, it can and it's easy, but if the file doesn't exist,
you can't be guaranteed that you're getting the right file name. So
one approach would be to add something like REALGetFolderItemName;
with that and the FSSpec and a good understanding of Mac APIs, you
could do it.

>PS: If you add API stuff, please add accessors to all the handels of the
>classes, so we can use them as parameters to ours.

We try to add accessors wherever we can, but that's a separate issue
-- let's try to keep this thread focused.

- Joe

Re: FSRef support in plugin API
Date: 05.06.02 00:22 (Tue, 04 Jun 2002 16:22:53 -0700)
From: Paul Mitchum
On 6/4/02 3:08 PM, "Joseph J. Strout" <<email address removed>> wrote:

> Hi gang,
>
> I'm currently working on the plugin API.

Rockin. :-)

> One thing some plugin authors have asked for are access to FSRefs to and from
> FolderItems. But this turns out to be rather tricky to support much better
> than it's supported already.
[..]

<http://groups.google.com/groups?selm=mwron-0FC922.12405002072001%40enews.ne
wsguy.com&output=gplain>

Maybe you should talk to the PowerPlant folks. :-)

REALFSSpecFromFolderItem always returns true, but why should
REALFSRefFromFolderItem? If the file doesn't exist (or if there's no HFS+
support), it can return false and the user can try to get an FSSpec.

REALFolderItemExists would be helpful, too, but not strictly on-topic.

Re: FSRef support in plugin API
Date: 05.06.02 03:41 (Tue, 04 Jun 2002 22:41:29 -0400)
From: Alfred Van Hoek
on 6/4/02 6:08 PM, Joseph J. Strout at <email address removed> wrote:

> I'm currently working on the plugin API. One thing some plugin
> authors have asked for are access to FSRefs to and from FolderItems.
> But this turns out to be rather tricky to support much better than
> it's supported already.
>
> If the FolderItem in question refers to a file that already exists,
> then the existing APIs suffice -- you can convert an FSRef to/from an
> FSSpec by using FSpMakeFSRef and FSGetCatalogInfo.
>
> But if you want to refer to a file that doesn't exist, then this is
> much harder. In general you have to use something like the FSRef of
> the parent, plus the name of the file you have in mind. But this
> pattern doesn't work for the root directory of a volume (which has no
> parent).
>
> So, I'm wondering if anybody has a pressing need to pass references
> to files that don't exist to/from a plugin, and what the details of
> that need are. Perhaps that will let us come up with an API that
> hides as much of this unpleasantness as possible.

I believe that REALfolderItem should know about HFSUniStr255:

HFSUniStr255 unicodeName;

we now have to access/create an FSSpec to get to it ourselves, something
like:
OSErr err = PStringGetUnicodeName(fsspec.name, kTextEncodingUnknown,
&unicodeName);
Str255 hfsName;
err = UnicodeNameGetPString(unicodeName.length, unicodeName.unicode,
kTextEncodingUnknown, hfsName);

return REALbuildString(&hfsName[1], hfsName[0]);

With respect to other enhancements:

1)
Sanctioning of the REALentry SDK (this should not take any work). You
probably know how important it is to me and Björn. It allows to provide a
plugin(s) with many classes in different resources, while overloading
constructors, taking instances of objects, allow for a modular development.

2)
Instantiation of custom classes from the RB environment in the plugin, which
is probably a major task. Something like this would allow the generation of
instances of a custom class that implement events in an asynchronous
callback to be put into a queue and taken care of in the EventFilter. It
avoids usage of selectors and cloning of instances; usage of selectors and
cloned instances are a workaround though.

I am happy that the REALeventInstance declaration works since 4.0.2. It
works like a charm and does add functionality.

Then a note. Your post looks like things are being done in a hurry, and
suggests that instantiation of custom classes is something that may be
implemented in version 6, later or never.

Nonetheless, I am looking forward :)

Alfred

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

Re: FSRef support in plugin API
Date: 05.06.02 10:11 (Wed, 05 Jun 2002 11:11:40 +0200)
From: François Menneteau <


Alfred Van Hoek wrote:

With respect to other enhancements:

>

I would be very very happy if class extension could have custom data.

Re: FSRef support in plugin API
Date: 05.06.02 11:17 (Wed, 05 Jun 2002 05:17:33 -0500)
From: Chad J McQuinn
On 6/4/02 5:08 PM, "Joseph J. Strout" <<email address removed>> wrote:

> But if you want to refer to a file that doesn't exist, then this is
> much harder. In general you have to use something like the FSRef of
> the parent, plus the name of the file you have in mind. But this
> pattern doesn't work for the root directory of a volume (which has no
> parent).

You could simplify this a bit maybe as follows

bool REALFSRefFromFolderItem(REALfolderItem f, FSRef* ref, HFSUniStr255*
name);

If name->length is set to 0 on output, then the FSRef refers to the actual
file; if the length is positive then the FSRef is for the parent directory
and the name is the file's name.

Pass NULL for name if you're only interested in an FSRef for the actual file
(in which case false is returned if it doesn't exist). This would avoid
having to create a dummy HFSUniStr255 (quite large as stack objects go) when
you don't need or want it.

Pass NULL for 'ref' if you're only interested in the name (which should
always succeed for a valid folderitem).

In general I don't like such one-size fits all API's; this one reminds me a
bit of FSGetCatalogInfo, which stinks. But as you say, FSRefs in the general
case can be a bit tricky, and somehow I think this simplifies it.

> So, I'm wondering if anybody has a pressing need to pass references
> to files that don't exist to/from a plugin, and what the details of
> that need are. Perhaps that will let us come up with an API that
> hides as much of this unpleasantness as possible.

I would say the biggest need is for passing folderitems that do not exist
INTO plugins (to specify a destination file for some operation, for
example). Rarely have I needed to pass one out, but it might also be nice to
have an API like

REALfolderItem REALFolderItemFromParentFSRef(FSRef& parent, HFSUniStr255&
fileName);

-Chad

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

Re: FSRef support in plugin API
Date: 05.06.02 14:54 (Wed, 5 Jun 2002 06:54:52 -0700)
From: Joseph J. Strout
At 5:17 AM -0500 6/5/02, Chad J McQuinn wrote:

>You could simplify this a bit maybe as follows
>
>bool REALFSRefFromFolderItem(REALfolderItem f, FSRef* ref, HFSUniStr255*
>name);

Thanks Chad, that's a good idea and neater than anything I had come up with.

>In general I don't like such one-size fits all API's; this one reminds me a
>bit of FSGetCatalogInfo, which stinks. But as you say, FSRefs in the general
>case can be a bit tricky, and somehow I think this simplifies it.

Right, that's my feeling too.

>I would say the biggest need is for passing folderitems that do not exist
>INTO plugins (to specify a destination file for some operation, for
>example). Rarely have I needed to pass one out, but it might also be nice to
>have an API like
>
>REALfolderItem REALFolderItemFromParentFSRef(FSRef& parent, HFSUniStr255&
>fileName);

Right, that would work as long as you're not trying to specify a root
directory with it -- but in that case, you could convert it to an
FSSpec and use REALFolderItemFromFSSpec.

Thanks,
- Joe

Re: FSRef support in plugin API
Date: 05.06.02 23:18 (Wed, 05 Jun 2002 17:18:39 -0500)
From: Chad J McQuinn
On 6/5/02 8:54 AM, "Joseph J. Strout" <<email address removed>> wrote:

>> REALfolderItem REALFolderItemFromParentFSRef(FSRef& parent, HFSUniStr255&
>> fileName);
>
> Right, that would work as long as you're not trying to specify a root
> directory with it -- but in that case, you could convert it to an
> FSSpec and use REALFolderItemFromFSSpec.

Ick...I hadn't thought of that. Maybe a better choice would be

REALfolderItem REALFolderItemFromFSRef(FSRef& ref, HFSUniStr255* fileName);

If fileName is NULL on entry, then the FSRef refers to the file; otherwise
it is a parent+name combination.

-Chad

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

Re: FSRef support in plugin API
Date: 06.06.02 11:46 (Thu, 6 Jun 2002 12:46:30 +0200)
From: Christian Schmitz
> On 6/5/02 8:54 AM, "Joseph J. Strout" <<email address removed>> wrote:
>
> Ick...I hadn't thought of that. Maybe a better choice would be
>
> REALfolderItem REALFolderItemFromFSRef(FSRef& ref, HFSUniStr255* fileName);
>
> If fileName is NULL on entry, then the FSRef refers to the file; otherwise
> it is a parent+name combination.

But on Mac OS 8.6 I still need a FSSpec...

Maybe FSSpec and FSRef functions? And FSRef only working on Mac OS 9 and
later?

Mfg
Christian

Re: FSRef support in plugin API
Date: 06.06.02 20:51 (Thu, 06 Jun 2002 14:51:06 -0500)
From: Chad J McQuinn
On 6/6/02 5:46 AM, "Christian Schmitz" <<email address removed>>
wrote:
> But on Mac OS 8.6 I still need a FSSpec...
>
> Maybe FSSpec and FSRef functions? And FSRef only working on Mac OS 9 and
> later?

There already are FSSpec functions, I don't think Joe said anything about
removing them.

-Chad

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

Re: FSRef support in plugin API
Date: 04.06.02 23:35 (Tue, 4 Jun 2002 15:35:55 -0700)
From: Thomas Tempelmann
Joseph J. Strout wrote:

> One thing some plugin
>authors have asked for are access to FSRefs to and from FolderItems.
>But this turns out to be rather tricky to support much better than
>it's supported already.

I agree. I find it quite unnecessary to add FSRef support to the
plugin API because, as you explained, one can easily and without
trouble convert between FSRefs and FSSpecs.

I'd rather see improvements in other, more urgent, areas of the API,
where we're currently entirely at loss.

May we make suggestions?

E.g, support for life updating with Einhugur's Grid controls by
allowing the control to suppress the "Auto Wait" cursor?

And, of course, the most important one, access the new strings'
encoding property, in creastion and reading.

Thomas

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

Re: FSRef support in plugin API
Date: 04.06.02 23:50 (Tue, 04 Jun 2002 17:50:10 -0500)
From: Will Cosgrove
Hi All,

>> One thing some plugin
>> authors have asked for are access to FSRefs to and from FolderItems.
>> But this turns out to be rather tricky to support much better than
>> it's supported already.
>
> I agree. I find it quite unnecessary to add FSRef support to the
> plugin API because, as you explained, one can easily and without
> trouble convert between FSRefs and FSSpecs.

Whoa, I would like to see FSRef support. Sure we can convert FSSpecs to
FSRefs, but why not just add it to the API, it's not that hard (unless the
file doesn't exist that is). It would be fairly trivial to add, so why not
just add it.

As for FSRefs when files don't exist, I wouldn't worry about it. When
plugin developers start calling FSRef code they should be aware that the
file has to exist, that's the nature of FSRef.

That's my .02 cents.

Cheers,
Will

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

Re: FSRef support in plugin API
Date: 04.06.02 23:52 (Tue, 4 Jun 2002 15:52:20 -0700)
From: Joseph J. Strout
At 5:50 PM -0500 6/4/02, Will Cosgrove wrote:

>Whoa, I would like to see FSRef support. Sure we can convert FSSpecs to
>FSRefs, but why not just add it to the API, it's not that hard (unless the
>file doesn't exist that is). It would be fairly trivial to add, so why not
>just add it.

Because time is short, and I don't see how we could make it much
easier than Apple's APIs already do -- it's just one toolbox call to
convert in either direction. I'm more concerned about the case of
nonexistent files.

>As for FSRefs when files don't exist, I wouldn't worry about it. When
>plugin developers start calling FSRef code they should be aware that the
>file has to exist, that's the nature of FSRef.

OK, thanks for the feedback (to all, BTW).

Best,
- Joe

Re: FSRef support in plugin API
Date: 05.06.02 00:04 (Tue, 04 Jun 2002 18:04:30 -0500)
From: Will Cosgrove
>> Whoa, I would like to see FSRef support. Sure we can convert FSSpecs to
>> FSRefs, but why not just add it to the API, it's not that hard (unless the
>> file doesn't exist that is). It would be fairly trivial to add, so why not
>> just add it.
>
> Because time is short, and I don't see how we could make it much
> easier than Apple's APIs already do -- it's just one toolbox call to
> convert in either direction. I'm more concerned about the case of
> nonexistent files.

Well, heck, if time is short, why are we having this thread? Most of us
already know how to convert FSSpecs to FSRefs so why add it? I thought it
was just to make life easier, but if it's going to stress you guys, don't
bother.

Cheers,
Will

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

Re: FSRef support in plugin API
Date: 05.06.02 04:52 (Tue, 4 Jun 2002 20:52:15 -0700)
From: Joseph J. Strout
At 6:04 PM -0500 6/4/02, Will Cosgrove wrote:

>Well, heck, if time is short, why are we having this thread? Most of us
>already know how to convert FSSpecs to FSRefs so why add it? I thought it
>was just to make life easier, but if it's going to stress you guys, don't
>bother.

Right, I got that from you (and thanks). The point of this thread is
to see if anyone needs what you CAN'T already do: get (or return) a
reference to a file that doesn't exist (without going through the
FSSpec bottleneck).

- Joe

Re: FSRef support in plugin API
Date: 05.06.02 00:34 (Tue, 4 Jun 2002 16:34:27 -0700)
From: Thomas Tempelmann
Will Cosgrove wrote:

>so why not
>just add it.

Because it requires work, and Joe does not get often to work on
the plugin API, and this little time is too value to be wasted
on things we can work-around ourselves. IMHO.

But I just realized that Christian and Joe are indeed finding
cases where additional support is required: if a User specifies
a long file name (>31 chars) explicitly for creation of a new
file or for a rename.

I won't oppose to this, but I am against other "enhancements"
if it takes Joe more than just a few minutes to implement it.
Not that I'd get to vote, but I find try to be careful about
what I ask with pressure to be added to the API as long as the
time Joe gets for it is so little.

Thomas

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

Re: FSRef support in plugin API
Date: 05.06.02 15:46 (Wed, 5 Jun 2002 07:46:35 -0700)
From: Thomas Tempelmann
François Menneteau wrote:

>I would be very very happy if class extension could have custom data.

I believe that this won't happen soon, if ever. The internal workings
of RB's class structures are probably preventing this.

Thomas

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

Re: FSRef support in plugin API
Date: 05.06.02 15:54 (Wed, 05 Jun 2002 16:54:32 +0200)
From: François Menneteau <


Thomas Tempelmann wrote:

> François Menneteau wrote:
>
> >I would be very very happy if class extension could have custom data.
>
> I believe that this won't happen soon, if ever. The internal workings
> of RB's class structures are probably preventing this.

Arg!
-

Re: FSRef support in plugin API
Date: 05.06.02 16:36 (Wed, 5 Jun 2002 08:36:24 -0700)
From: Joseph J. Strout
At 7:46 AM -0700 6/5/02, Thomas Tempelmann wrote:

>François Menneteau wrote:
>
>>I would be very very happy if class extension could have custom data.
>
>I believe that this won't happen soon, if ever. The internal workings
>of RB's class structures are probably preventing this.

That's right, and in fact, it may be difficult to support class
extensions at all in future versions of RB. The next release of the
SDK will probably include some verbiage warning you to avoid class
extensions, and to use subclassing instead wherever possible.

Best,
- Joe

-

Re: FSRef support in plugin API
Date: 05.06.02 18:34 (Wed, 5 Jun 2002 19:34:28 +0200)
From: Christian Schmitz
> That's right, and in fact, it may be difficult to support class
> extensions at all in future versions of RB.

Why?

Mfg
Christian

Re: FSRef support in plugin API
Date: 05.06.02 18:51 (Wed, 05 Jun 2002 10:51:27 -0700)
From: Mars Saxman
<email address removed> wrote:

>> That's right, and in fact, it may be difficult to support class
>> extensions at all in future versions of RB.
>
> Why?

The class extension system was designed around the old compiler's internal
structure. Our new compiler architecture is organized along substantially
different lines, and it will be hard to design a sensible way for it to
support class extensions.

Whether we continue to support class extensions or end up deciding to drop
them, it makes sense to make all internal classes usefully subclassable.

Mars Saxman
REAL Software

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

Re: FSRef support in plugin API
Date: 05.06.02 20:07 (Wed, 5 Jun 2002 21:07:30 +0200)
From: Christian Schmitz
> <email address removed> wrote:
>
> The class extension system was designed around the old compiler's internal
> structure. Our new compiler architecture is organized along substantially
> different lines, and it will be hard to design a sensible way for it to
> support class extensions.

Still: Why?

May it not be possible to make this like a method which is local to the
class?

Let's say I make a subclass of Graphics with a function drawarc and
Micono makes a subclass of Graphics with a function fillarc.

Now, how can I use both subclasses together?

Mfg
Christian

Re: FSRef support in plugin API
Date: 05.06.02 22:08 (Wed, 05 Jun 2002 14:08:34 -0700)
From: Paul Mitchum
On 6/5/02 12:07 PM, "Christian Schmitz" <<email address removed>>
wrote:

>> The class extension system was designed around the old compiler's internal
>> structure. Our new compiler architecture is organized along substantially
>> different lines, and it will be hard to design a sensible way for it to
>> support class extensions.
>
> Still: Why?
>
> May it not be possible to make this like a method which is local to the
> class?
>
> Let's say I make a subclass of Graphics with a function drawarc and
> Micono makes a subclass of Graphics with a function fillarc.
>
> Now, how can I use both subclasses together?

This is exactly why I've chosen to make class extensions rather than
subclasses (or... gack... global methods) for Application and Window. If I
make an Application or Window subclass, then users are locked into my
plug-in's feature set and no one else's.

This has it's attraction, from a Microsoft kind of viewpoint <grin>, but is
not so good if you want interoperability and other forms of hand-holding
happiness.

Also, at the moment I'm working on a wrapper class to augment FolderItem.
It's darned convenient to have RB code like this:

aFolderItem.WrapperClass.someMethod

...which, without extending FolderItem, would look like this:

dim w as WrapperClass
w = new WrapperClass(folderItem)
w.someMethod

Is RB convenient or not? :-)

I'd suggest that if RS had asked plug-in authors whether class extensions
were important *before* designing them out of the compiler architecture, it
might not be so hard to support them now.

Re: FSRef support in plugin API
Date: 05.06.02 23:27 (Wed, 5 Jun 2002 15:27:19 -0700)
From: Joseph J. Strout
At 2:08 PM -0700 6/5/02, Paul Mitchum wrote:

>I'd suggest that if RS had asked plug-in authors whether class extensions
>were important *before* designing them out of the compiler architecture, it
>might not be so hard to support them now.

Please don't jump to conclusions. We didn't "design them out" but
we're not willing to double the cost (and time to completion) of the
new compiler for them, either. Maybe we won't have to. Time will
tell. This is just a gentle warning that, perhaps, someday we all
might have to consider the possibility of thinking about the idea of
maybe looking into no longer having class extensions.

Thanks,
- Joe

Re: FSRef support in plugin API
Date: 05.06.02 23:55 (Wed, 05 Jun 2002 15:55:22 -0700)
From: Paul Mitchum
On 6/5/02 3:27 PM, "Joseph J. Strout" <<email address removed>> wrote:

> At 2:08 PM -0700 6/5/02, Paul Mitchum wrote:
>
>> I'd suggest that if RS had asked plug-in authors whether class extensions
>> were important *before* designing them out of the compiler architecture, it
>> might not be so hard to support them now.
>
> Please don't jump to conclusions. We didn't "design them out" but
> we're not willing to double the cost (and time to completion) of the
> new compiler for them, either. Maybe we won't have to. Time will
> tell. This is just a gentle warning that, perhaps, someday we all
> might have to consider the possibility of thinking about the idea of
> maybe looking into no longer having class extensions.

Then let me restate:

Thank you for floating this balloon. Now you know that class extensions are
important to some folks, and why they think that. Please keep it in mind
while you're figuring out what to keep and what to toss out.

Re: FSRef support in plugin API
Date: 06.06.02 01:02 (Thu, 06 Jun 2002 00:02:11 +0000)
From: Einhugur Software
on 5.6.2002 22:27, Joseph J. Strout at <email address removed> wrote:

Some will feel this to be strange coming from a Plugin author, but I fully
agree with dropping the Class extensions, Mostly because they have always
been a prone to cause problems, linker errors and such.

Yes the idea of class extensions was kinda cool but it never fully worked
safely in all cases.

I changed to methods that take the class as a parameter a long time ago,
which cut down user support costs a lot, simply because it eliminated linker
errors. Class extensions make cool syntax but they don't offer anything that
you simply cannot do with a global method that takes the class as a
parameter.

So yes rather than having broken class extensions then I vote for remove
them. (not that my vote maters here)

> At 2:08 PM -0700 6/5/02, Paul Mitchum wrote:
>
>> I'd suggest that if RS had asked plug-in authors whether class extensions
>> were important *before* designing them out of the compiler architecture, it
>> might not be so hard to support them now.
>
> Please don't jump to conclusions. We didn't "design them out" but
> we're not willing to double the cost (and time to completion) of the
> new compiler for them, either. Maybe we won't have to. Time will
> tell. This is just a gentle warning that, perhaps, someday we all
> might have to consider the possibility of thinking about the idea of
> maybe looking into no longer having class extensions.
>
> Thanks,
> - Joe

--  
______________________________________________________________________
Björn Eiríksson <email address removed>
Einhugur Software <email address removed>
http://www.einhugur.com
______________________________________________________________________
Einhugur Software has sold its products in 39 countries world wide.
______________________________________________________________________
For support: <email address removed>
For bug reports: <email address removed>
To post on the maillist: <email address removed>




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

Re: FSRef support in plugin API
Date: 05.06.02 16:45 (Wed, 05 Jun 2002 17:45:29 +0200)
From: François Menneteau <


"Joseph J. Strout" wrote:

> At 7:46 AM -0700 6/5/02, Thomas Tempelmann wrote:
>
> >François Menneteau wrote:
> >
> >>I would be very very happy if class extension could have custom data.
> >
> >I believe that this won't happen soon, if ever. The internal workings
> >of RB's class structures are probably preventing this.
>
> That's right, and in fact, it may be difficult to support class
> extensions at all in future versions of RB. The next release of the
> SDK will probably include some verbiage warning you to avoid class
> extensions, and to use subclassing instead wherever possible.
>

But this is not always the case.
Typically, I have extended the graphic class. Unless there is a way to
tell RB to use a subclass of the graphic class to all object that have a
graphic property (mainly canvas and picture) there is no other solution
that to use a class extension.

-

Re: FSRef support in plugin API
Date: 06.06.02 02:55 (Wed, 5 Jun 2002 18:55:11 -0700)
From: Thomas Tempelmann
Einhugur Software wrote:

>I fully agree with dropping the Class extensions, Mostly because they have
>always been a prone to cause problems, linker errors and such.

_That_ problem could be dealt with if the compiler would simply
take notes of the plugins involved when it compiles code that uses
methods from those plugins. This information is available, after all.

I find your work-around, which would be to provide a LOT of global
methods, rather a bad thing: It adds clutter (just think of the tab-
completion functionality, which will come up with all those globals
you may have in your plugins) and is even more likely to cause name
collisions with globals from other plugins user defined modules.

Thomas

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

Re: FSRef support in plugin API
Date: 06.06.02 04:36 (Wed, 05 Jun 2002 23:36:38 -0400)
From: Alfred Van Hoek
on 6/5/02 9:55 PM, Thomas Tempelmann at <email address removed> wrote:

> _That_ problem could be dealt with if the compiler would simply
> take notes of the plugins involved when it compiles code that uses
> methods from those plugins. This information is available, after all.
>
> I find your work-around, which would be to provide a LOT of global
> methods, rather a bad thing: It adds clutter (just think of the tab-
> completion functionality, which will come up with all those globals
> you may have in your plugins) and is even more likely to cause name
> collisions with globals from other plugins user defined modules.

Granted that global methods is not a really good thing. We have, however,
to define the purpose of extending a class; Currently, I believe it is
carried out by plugin authors because of lack of accessors. The folderItem
is a willing object to be extended, and I have done this quite a lot, but it
is done for a specific purpose:

dim myMovie as WiredMovie
dim f as folderItem

f = GetFolderitem("myDemoMovie.mov")
myMovie = f.OpenAsWiredMovie

The drawback is you can only create a myMovie of classType WiredMovie,
because the implementation calls REALnewInstance("WiredMovie"). We cannot
call something like:

dim myMovie as mySubClassedWiredMovie
myMovie = f.OpenAsWiredMovie // will fail

The real solution is:

myMovie = new mySubClassedWiredMovie(GetFolderitem("myDemoMovie.mov"))

(The "myMovie = f.OpenAsWiredMovie" I used to think was better, because it
conforms to f.OpenAsMovie. However, it limits the
REALbasic_User_Experience.)

If there is a need to extend the graphics class, I rather would see some
additional accessors to this class. We could then call
REALBuildGraphicsFromxxx or other new API calls. I would suggest let's get
those accessors and think about what is really required to ""extend"" a
class in the context of plugin development.

Alfred

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

Re: FSRef support in plugin API
Date: 06.06.02 04:53 (Wed, 5 Jun 2002 20:53:49 -0700)
From: Thomas Tempelmann
Alfred Van Hoek wrote:

>Currently, I believe it is
>carried out by plugin authors because of lack of accessors. The folderItem
>is a willing object to be extended

Well, what about the MemoryBlock? My MB extension is still quite
popular, from what I can tell from the downloads (that is, it's the
most popular of all my plugins, while most of the others are NOT
class extensions).

Thomas

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

Re: FSRef support in plugin API
Date: 06.06.02 11:46 (Thu, 6 Jun 2002 12:46:31 +0200)
From: Christian Schmitz
Hi,

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? 600 global functions
(of around 800 in the plugin)
Or one big plugin to blow RB apps to 5 MB each?

Mfg
Christian

Re: FSRef support in plugin API
Date: 06.06.02 15:32 (Thu, 6 Jun 2002 07:32:23 -0700)
From: Joseph J. Strout
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.

>Or one big plugin to blow RB apps to 5 MB each?

Your FolderItem plus MemoryBlock extensions come out to 3 MB?!?
That's hard to imagine.

Best,
- Joe

Re: FSRef support in plugin API
Date: 06.06.02 17:33 (Thu, 6 Jun 2002 18:33:35 +0200)
From: Christian Schmitz
> At 12:46 PM +0200 6/6/02, Christian Schmitz wrote:
>
> >Or one big plugin to blow RB apps to 5 MB each?
>
> Your FolderItem plus MemoryBlock extensions come out to 3 MB?!?
> That's hard to imagine.

I have for example this nice code which does JPEG and TIFF.
And the JPEG code for compression is 120K, for decompression another
120K and for TIFF it's 300 K.

This all together would be large with all the others...

(And 5 MB was a guess...)

Mfg
Christian