Xojo Conferences
XDCMay2019MiamiUSA

Re: [ANN] ElfData plugin 1.0b5 (Real Studio Plugins Mailinglist archive)

Back to the thread list
Previous thread: Objective-C framework and plugin
Next thread: Re: RB 5.1 BREAK debugging of plugins ???!!!


Re: [ANN] ElfData plugin 1.0b5   -   Theodore H. Smith
  Re: [ANN] ElfData plugin 1.0b5   -   Charles Yeomans
  Re: [ANN] ElfData plugin 1.0b5   -   Craig A. Finseth
  Re: [ANN] ElfData plugin 1.0b5   -   Theodore H. Smith
  Re: [ANN] ElfData plugin 1.0b5   -   Theodore H. Smith
   Re: [ANN] ElfData plugin 1.0b5   -   Charles Yeomans
  Re: [ANN] ElfData plugin 1.0b5   -   Theodore H. Smith
   Re: [ANN] ElfData plugin 1.0b5   -   Chris Little
    Re: [ANN] ElfData plugin 1.0b5   -   Christian Schmitz
     Re: [ANN] ElfData plugin 1.0b5   -   Daniel Chiaramello
      Re: [ANN] ElfData plugin 1.0b5   -   Chris Little
      Re: [ANN] ElfData plugin 1.0b5   -   Craig A. Finseth
       Re: [ANN] ElfData plugin 1.0b5   -   Norman Palardy
     Re: [ANN] ElfData plugin 1.0b5   -   Chris Little
    Re: [ANN] ElfData plugin 1.0b5   -   Jan Erik Moström <
     [ANN] ElfData plugin 1.0b5   -   Theodore H. Smith
      Passing in and out a color ref   -   Will Cosgrove
     Re: Needs PDF Plugins   -   nauckt englram.de
   Re: [ANN] ElfData plugin 1.0b5   -   John H. Guillory

Re: [ANN] ElfData plugin 1.0b5
Date: 01.06.03 16:36 (Sun, 1 Jun 2003 16:36:49 +0100)
From: Theodore H. Smith

Does anyone have some thoughts on my extensive use of prefixes and
suffixes? I'm not completely sure all of them are necessary. While I do
think having the "L" in ElfData.UpperCaseL is a good thing because you
can see at a glance that it doesn't do anything without a valid "Lexer"
stored in ElfData.Lexer, I'm not sure that the extra thing to remember
("L") is more important than to remember that you must put a lexer into
ElfData to use it.

Perhaps I could be following the "three strikes and you're out" thingy?
So while I only have two lexer-only functions, I could leave them
without the L? Of course I am going to add more lexer functions though,
like .FoldCaseL, and maybe other Unicode related functions.

The property cIsASCII, while it does remind us that there is something
special about it, I'm not sure it is worth making the plugin more
complex?

Does anyone have some thoughts on which prefixes/suffixes should be
removed and more importantly why? Or why to keep them also if you think
that? The letters are listed here:

http://www.elfdata.com/plugin/design.html

I'll probably take a good look at this soon, but right now I'll be
working on TUFF for a bit, then my sound ship plugin.

> * Clarified functionality, by replacing ElfData.UpperCaseM with
> ElfData.UpperCaseL.

---
A searchable archive of this list is available at:
<http://support.realsoftware.com/listarchives/search.php>

Unsubscribe:
<mailto:<email address removed>>

Subscribe to the digest:
<mailto:<email address removed>>

Re: [ANN] ElfData plugin 1.0b5
Date: 02.06.03 20:42 (Mon, 2 Jun 2003 15:42:27 -0400)
From: Charles Yeomans

On Sunday, June 1, 2003, at 11:36 AM, Theodore H. Smith wrote:

>
> Does anyone have some thoughts on my extensive use of prefixes and
> suffixes? I'm not completely sure all of them are necessary. While I
> do think having the "L" in ElfData.UpperCaseL is a good thing because
> you can see at a glance that it doesn't do anything without a valid
> "Lexer" stored in ElfData.Lexer, I'm not sure that the extra thing to
> remember ("L") is more important than to remember that you must put a
> lexer into ElfData to use it.
>
> Perhaps I could be following the "three strikes and you're out"
> thingy? So while I only have two lexer-only functions, I could leave
> them without the L? Of course I am going to add more lexer functions
> though, like .FoldCaseL, and maybe other Unicode related functions.
>
> The property cIsASCII, while it does remind us that there is something
> special about it, I'm not sure it is worth making the plugin more
> complex?
>
> Does anyone have some thoughts on which prefixes/suffixes should be
> removed and more importantly why? Or why to keep them also if you
> think that? The letters are listed here:
>
> http://www.elfdata.com/plugin/design.html
>

I think that the perceived need for a relatively complicated naming
convention is a sign that you should rethink the interface. For the
example you offer, I wonder if it wouldn't be better to write an
overloaded version of UpperCase that takes a Lexer as parameter. This
way the user doesn't need to think "hmmm, did I set that Lexer
property?". This inspires another question -- does ElfData even need a
Lexer property? Unless an ElfData object needs to hang on to it for
some other reason, why not ask that such an object be passed in as
needed? The ElfData user can create the object once and worry about
storing it if object creation cost is a concern in a particular
situation.

Charles Yeomans

---
A searchable archive of this list is available at:
<http://support.realsoftware.com/listarchives/search.php>

Unsubscribe:
<mailto:<email address removed>>

Subscribe to the digest:
<mailto:<email address removed>>

Re: [ANN] ElfData plugin 1.0b5
Date: 23.03.01 12:24 (Mon, 2 Jun 2003 16:26:48 -0500 (CDT))
From: Craig A. Finseth
Does anyone have some thoughts on my extensive use of prefixes and
suffixes? I'm not completely sure all of them are necessary. While I do

IMHO, a prefix/suffix is good if it corresponds to a useful distinction
in the user's mind.

For example, one might have:

Get_Property()
and
Set_Property()

(we're talking general here...not getting into whether this interface
is better or worse than operator overloading and related).

Here, a prefix makes conceptual sense: there are two related routines
that differ in an externally obvious way and hence have different but
related names.

Similarly, if one had to versions of a routine:

LowerCaseA
LowerCaseU

which convert a string to lower case. We'll assume that there are
good reasons for two routings and not using overloading or run-time
detection. The first (again, hypothetical illustrative examples)
might only work on ASCII text (values 0-127 decimal) and the other
on full UNICODE. Again, conceptually related routines that differ
in user-visible functionality.

I suggest that it would _not_ be reasonable to use a prefix/suffix
to mark part of the behavior unless there is a reason.

For example, if there were a property that indicated the ASCII/UNICODE
behavior and all versions of the routine used it, defining:

LowerCaseP

would not make sense.

Unless, of course, there was also:

UpperCaseA
UpperCaseU
UpperCaseP

in this case, definining LowerCaseP would be reasonable. (Assuming,
of course, that it would not otherwise make sense to define LowerCaseA
and LowerCaseU).

Desiging good interfaces is still an art form (:-).

Craig

---
A searchable archive of this list is available at:
<http://support.realsoftware.com/listarchives/search.php>

Unsubscribe:
<mailto:<email address removed>>

Subscribe to the digest:
<mailto:<email address removed>>

Re: [ANN] ElfData plugin 1.0b5
Date: 02.06.03 15:36 (Mon, 2 Jun 2003 15:36:39 +0100)
From: Theodore H. Smith

I found out that the download links is wrong, sorry about this. I fixed
the HTML. Heres the download link anyhow:

www.elfdata.com/plugin/elfdataplugin.sit

---
A searchable archive of this list is available at:
<http://support.realsoftware.com/listarchives/search.php>

Unsubscribe:
<mailto:<email address removed>>

Subscribe to the digest:
<mailto:<email address removed>>

Re: [ANN] ElfData plugin 1.0b5
Date: 03.06.03 14:46 (Tue, 3 Jun 2003 14:46:34 +0100)
From: Theodore H. Smith
> think that the perceived need for a relatively complicated naming
> convention is a sign that you should rethink the interface.

Good point. Unfortunately I didn't explain the full situation to you.

UpperCase needs a lexer to work, so it would be an obligatory param.
Casing functions currently need a lexer, but the rest of the "lexer
using" functions it is optional.

So what about the other methods optionally use lexers? Like InStr,
Equals, Compare, ReplaceAll? Should they all have optional params?

I already have 3 versions of InStr, (compared to RB's 2 versions):
1) Searches the whole thing
2) From a start pos
3) From a start pos to the end pos

With an optional lexer, that takes it to 6 versions. I'm not even sure
if REALbasic can handle this well.

In fact, by making the lexer a property, this will simplify the design
(I did get it down to taking only 4 bits from my flag field, so its not
much RAM, of course it can only store 16 possible lexers including the
nil lexer).

I'm more wondering if I should just omit the L, without changing the
design. I think I could do it, because instead of letting them remember
"L", they could remember "Case", where I would state that all casing
functions need a valid lexer. They do and will actually, because
conceptually a casing function is a lexicographic-only function, while
searching for a string can be done binary.

> For the
> example you offer, I wonder if it wouldn't be better to write an
> overloaded version of UpperCase that takes a Lexer as parameter. This
> way the user doesn't need to think "hmmm, did I set that Lexer
> property?". This inspires another question -- does ElfData even need a
> Lexer property? Unless an ElfData object needs to hang on to it for
> some other reason, why not ask that such an object be passed in as
> needed? The ElfData user can create the object once and worry about
> storing it if object creation cost is a concern in a particular
> situation.

Thanks for taking the time, a good answer unfortunately on my
incomplete description.

Re: [ANN] ElfData plugin 1.0b5
Date: 03.06.03 15:27 (Tue, 3 Jun 2003 10:27:52 -0400)
From: Charles Yeomans

On Tuesday, June 3, 2003, at 09:46 AM, Theodore H. Smith wrote:

>> think that the perceived need for a relatively complicated naming
>> convention is a sign that you should rethink the interface.
>
> Good point. Unfortunately I didn't explain the full situation to you.
>
> UpperCase needs a lexer to work, so it would be an obligatory param.
> Casing functions currently need a lexer, but the rest of the "lexer
> using" functions it is optional.

If some functions require a lexer, then I'm not sure that ElfData
should have a Lexer property that the user must remember to set. One
alternative would be to require that a Lexer be passed in the
constructor. If there is a default choice of Lexer, then another
alternative would be to set it privately, possibly using lazy loading
to create it only once it's needed. Then people who want to use their
own Lexer could pass it in one of the functions.

>
> So what about the other methods optionally use lexers? Like InStr,
> Equals, Compare, ReplaceAll? Should they all have optional params?
>
> I already have 3 versions of InStr, (compared to RB's 2 versions):
> 1) Searches the whole thing
> 2) From a start pos
> 3) From a start pos to the end pos
>
> With an optional lexer, that takes it to 6 versions. I'm not even sure
> if REALbasic can handle this well.

I can't speak for plugins, but Rb does just fine with many overloaded
versions of a method. Since overloading is resolved at compile-time,
it should have no effect on performance or code size (except that it
might make your plugin a few bytes larger).

>
> In fact, by making the lexer a property, this will simplify the design
> (I did get it down to taking only 4 bits from my flag field, so its
> not much RAM, of course it can only store 16 possible lexers including
> the nil lexer).
>
> I'm more wondering if I should just omit the L, without changing the
> design. I think I could do it, because instead of letting them
> remember "L", they could remember "Case", where I would state that all
> casing functions need a valid lexer. They do and will actually,
> because conceptually a casing function is a lexicographic-only
> function, while searching for a string can be done binary.

This would work; my philosophy is to use the compiler as much as
possible; it remembers better than I do.

Charles Yeomans

---
A searchable archive of this list is available at:
<http://support.realsoftware.com/listarchives/search.php>

Unsubscribe:
<mailto:<email address removed>>

Subscribe to the digest:
<mailto:<email address removed>>

Re: [ANN] ElfData plugin 1.0b5
Date: 03.06.03 15:44 (Tue, 3 Jun 2003 15:44:14 +0100)
From: Theodore H. Smith
> I suggest that it would _not_ be reasonable to use a prefix/suffix
> to mark part of the behavior unless there is a reason.

Good point. I'm not sure about my "ElfDataStringK(String) as ElfData"
for example. I used K for konstant, IE to signify that it returns a
constant (unlike the other ElfData global methods). It is however the
only "K" function. On the other hand, for some reason this seems less
bothersome than some of my other prefixes or suffixes.

> LowerCaseP
>
> would not make sense.
>
> Unless, of course, there was also:
>
> UpperCaseA
> UpperCaseU
> UpperCaseP

I think thats a good summary.

> Desiging good interfaces is still an art form (:-).

Yes. I did put a lot of thought into my naming already in fact, but I
probably should have put even more.

Re: [ANN] ElfData plugin 1.0b5
Date: 03.06.03 20:22 (Tue, 03 Jun 2003 15:22:08 -0400)
From: Chris Little
on 6/3/03 10:44 AM, Theodore H. Smith at <email address removed> wrote:

>> I suggest that it would _not_ be reasonable to use a prefix/suffix
>> to mark part of the behavior unless there is a reason.
>
> Good point. I'm not sure about my "ElfDataStringK(String) as ElfData"
> for example. I used K for konstant, IE to signify that it returns a
> constant (unlike the other ElfData global methods). It is however the
> only "K" function. On the other hand, for some reason this seems less
> bothersome than some of my other prefixes or suffixes.
>

I would never connected a K with constant. That's the problem with short
little prefixes and suffixes. They only mean something to the original
author who doesn't really need them.

Chris


---
A searchable archive of this list is available at:
<http://support.realsoftware.com/listarchives/search.php>

Unsubscribe:
<mailto:<email address removed>>

Subscribe to the digest:
<mailto:<email address removed>>

Re: [ANN] ElfData plugin 1.0b5
Date: 03.06.03 21:09 (Tue, 3 Jun 2003 22:09:43 +0200)
From: Christian Schmitz
> I would never connected a K with constant. That's the problem with short
> little prefixes and suffixes. They only mean something to the original
> author who doesn't really need them.

Learn German ;-)

constant = Konstante

Mfg
Christian

Re: [ANN] ElfData plugin 1.0b5
Date: 04.06.03 09:24 (Wed, 4 Jun 2003 10:24:48 +0200)
From: Daniel Chiaramello
Well, the "k" prefix is very common to describe a constant - not only
in German...
If you ask all the developers you know what would be their preferred
prefix-suffix to describe a constant, I think that 80% (if not more)
will answer "k".

But that's kind-of off-topic...

Daniel.

Le mardi, 3 juin 2003, à 22:09 Europe/Paris, Christian Schmitz a écrit :

>> I would never connected a K with constant. That's the problem with
>> short
>> little prefixes and suffixes. They only mean something to the
>> original
>> author who doesn't really need them.
>
> Learn German ;-)
>
> constant = Konstante
>
> Mfg
> Christian

---
A searchable archive of this list is available at:
<http://support.realsoftware.com/listarchives/search.php>

Unsubscribe:
<mailto:<email address removed>>

Subscribe to the digest:
<mailto:<email address removed>>

Re: [ANN] ElfData plugin 1.0b5
Date: 04.06.03 14:16 (Wed, 04 Jun 2003 09:16:45 -0400)
From: Chris Little
And I've used it as a prefix for constants. As a suffix for a function
name, especially when it isn't clear what is constant is too cryptic.

Chris

on 6/4/03 4:24 AM, Daniel Chiaramello at <email address removed> wrote:

> Well, the "k" prefix is very common to describe a constant - not only
> in German...
> If you ask all the developers you know what would be their preferred
> prefix-suffix to describe a constant, I think that 80% (if not more)
> will answer "k".
>
> But that's kind-of off-topic...
>
> Daniel.
>
> Le mardi, 3 juin 2003, à 22:09 Europe/Paris, Christian Schmitz a écrit :
>
>>> I would never connected a K with constant. That's the problem with
>>> short
>>> little prefixes and suffixes. They only mean something to the
>>> original
>>> author who doesn't really need them.
>>
>> Learn German ;-)
>>
>> constant = Konstante
>>
>> Mfg
>> Christian

---
A searchable archive of this list is available at:
<http://support.realsoftware.com/listarchives/search.php>

Unsubscribe:
<mailto:<email address removed>>

Subscribe to the digest:
<mailto:<email address removed>>

Re: [ANN] ElfData plugin 1.0b5
Date: 23.03.01 12:32 (Wed, 4 Jun 2003 08:33:59 -0500 (CDT))
From: Craig A. Finseth
Well, the "k" prefix is very common to describe a constant - not only
in German...
If you ask all the developers you know what would be their preferred
prefix-suffix to describe a constant, I think that 80% (if not more)
will answer "k".

Unless they're C programmers, in which case all UPPERCASE is used
for constants (sort of). Many (:-)s.

Craig

---
A searchable archive of this list is available at:
<http://support.realsoftware.com/listarchives/search.php>

Unsubscribe:
<mailto:<email address removed>>

Subscribe to the digest:
<mailto:<email address removed>>

Re: [ANN] ElfData plugin 1.0b5
Date: 04.06.03 17:41 (Wed, 04 Jun 2003 10:41:21 -0600)
From: Norman Palardy
100% of the C/C++ programmers I know and have worked with use k

Apple and compiler vendors there have been doing that form for ....
gawd .... so long I cant recall the first time I saw it ... perhaps in
Think C

On Wednesday, June 4, 2003, at 07:33 AM, Craig A. Finseth wrote:

> Well, the "k" prefix is very common to describe a constant - not
> only
> in German...
> If you ask all the developers you know what would be their preferred
> prefix-suffix to describe a constant, I think that 80% (if not
> more)
> will answer "k".
>
> Unless they're C programmers, in which case all UPPERCASE is used
> for constants (sort of). Many (:-)s.

---
A searchable archive of this list is available at:
<http://support.realsoftware.com/listarchives/search.php>

Unsubscribe:
<mailto:<email address removed>>

Subscribe to the digest:
<mailto:<email address removed>>

Re: [ANN] ElfData plugin 1.0b5
Date: 04.06.03 14:14 (Wed, 04 Jun 2003 09:14:33 -0400)
From: Chris Little
on 6/3/03 4:09 PM, Christian Schmitz at <email address removed>
wrote:

>> I would never connected a K with constant. That's the problem with short
>> little prefixes and suffixes. They only mean something to the original
>> author who doesn't really need them.
>
> Learn German ;-)
>
> constant = Konstante
>

I assumed it was something like that. Of course having a language issue in
a plugin designed to help you work with unicode strings is somewhat ironic.

Chris

---
A searchable archive of this list is available at:
<http://support.realsoftware.com/listarchives/search.php>

Unsubscribe:
<mailto:<email address removed>>

Subscribe to the digest:
<mailto:<email address removed>>

Re: [ANN] ElfData plugin 1.0b5
Date: 23.03.01 12:18 (Tue, 3 Jun 2003 22:39:07 +0200)
From: Jan Erik Moström <
Chris Little <<email address removed>> (2003-06-03 15:22) wrote:

>I would never connected a K with constant. That's the problem with
>short little prefixes and suffixes. They only mean something to the
>original author who doesn't really need them.

8-)

Swedish: Constant => Konstant

jem

[ANN] ElfData plugin 1.0b5
Date: 01.06.03 13:50 (Sun, 1 Jun 2003 13:50:10 +0100)
From: Theodore H. Smith
The ElfData plugin has been updated to 1.0b5. Available from:

www.elfdata.com/plugin/

Version History:
* Totally re-did the technical reference, now comes from XML source and
uses a generating application.
* FastString.GetResult now has an "InheritFrom as ElfData" parameter.
* Fixed an obscure bug in .fUTF where we could get a fBigEndian = false
with UTF8 or Binary!
* Clarified functionality, by replacing ElfData.UpperCaseM with
ElfData.UpperCaseL.
* Implemented the Lexer API! Now other plugin authors can write lexer
plugins for the ElfData plugin. (A plugin to a plugin, basically).
* Updated the tests to make sure the bugs found don't come back. Update
the tests and documentation to reflect the changes listed.
* Wrote the "ASCII Insensitive" lexer "plugin plugin" and bundled it.
* Remove ElfDataCentral.NewIsFast to improve simplicity.

If the last you saw of the Techical reference was a bit "Crummy" black
and white version with partial examples, no links and not much style,
then you should be impressed by the new colorful interlinked
fully-exampled version.

So if you were put off that it was too hard to understand, you might
want to take a look now to see if it is easier.

The new technical refs are at:
www.elfdata.com/plugin/technicalref/

Re: [ANN] ElfData plugin 1.0b5
Date: 04.06.03 00:04 (Tue, 03 Jun 2003 18:04:17 -0500)
From: John H. Guillory
On Tue, 3 Jun 2003 22:39:07 +0200, you were caught stating that Re:
[ANN] ElfData plugin 1.0b5:

>>I would never connected a K with constant. That's the problem with
>>short little prefixes and suffixes. They only mean something to the
>>original author who doesn't really need them.

>Swedish: Constant => Konstant

O.k., Time for some Flame Bait....

1> I think overall the theory of adding crap to variable names to tell
you what type the variable type is, is down right stupid.... That's
what documentation is for.... C++ programmers may like it, but Real
Basic programmers don't need it....

2> The way MonkeyBread Software adds MBS is not only useful, but I can
see where it would help keep the variable names and methods from
conflicting with other similiar plugins.

3> Too many C++ Programs written in ENGLISH look much more easier to
read if you know HUNGARIAN, due to the Hungarian Notation. Even then,
I can't say that the hungarians want to read a C++ program.... 1-2
suffixes are o.k., but some programmers go beyond necessity by tacking
on 5-6 extra letters to tell you exactly what parameters the function
takes on as well as tacking on all those extra letters to the
paramaters (seeming much like redundancy myself)..... Why not just
declare your functions like:

UppercaseThatTakesAStringNamedSTR(StrTheString as String) as String

Seems to make more sense.... Of course, if you really want to bring
C++ functionality to Real Basic and get into all that, we can't just
pass a string.... We must first define a CUSTOM class that does
nothing more than add code to the project.... Maybe add a stupid
function or two that tells us if its been initialized or not, then
call it a "Safe String", and force all programmers to convert their
strings to our new "Safe String" format.... And we can create a new
INTEGER class that uses a 32-bit data space to store a 16-bit integer
and perform Error Checking to ensure that our variable is still the
same thing we set it before (AS IF OUR CPU's out to get us!!!! )

John H. Guillory
<email address removed>
Mat 19:26 KJV
(26) But Jesus beheld them, and said unto them, With men this is impossible; but with God all things are possible.

---
A searchable archive of this list is available at:
<http://support.realsoftware.com/listarchives/search.php>

Unsubscribe:
<mailto:<email address removed>>

Subscribe to the digest:
<mailto:<email address removed>>