[Lazarus] Easiest way to "case" strings

[Marco van de Voort]

On Thu, Mar 26, 2009 at 10:28:50AM +1000, Alexander Klenin wrote:
> > What problem does "for in" really solve?
> 
> Lack of iterators.

No it doesn't IMHO. And I assume that by "lack of iterators" you mean
in-language iterators?
 
> > Is having 6 levels of information
> > hiding (private,public,strict protected, strict private,protected,published)
> > or are the strict* ones just to stop the whining of people that come from
> > other languages?
> 
> No, it is not necessary, but handy sometimes.

One can give this "handy" moniker to every randomly thought up with an
example that shortens some random code fragment. IMHO it is meaningless.

It is about what a feature makes possible, and, in the rare cases of
synctactic sugar, how often it is used.

I'm also not entirely happy with the way dynamic arrays are set up. They
seem to be made mostly for COM use, the mandatory 0-basedness is unpascal
like etc.

However after initial resist, I started to use them, because they simplify a
lot of menial pointer code for simple dynamic memory use. 

I can live with such an argumentation. However, if I take the case of string
as example, I see only very rare occasions, and I wouldn't even use case of
string because it is so limited. If suddenly the cases wouldn't be
compiletime anymore (because they become user configurable or localised
values) you have to morph the entire block.

> I agree that these are not a big deal, and FPC can live without them quite
> fine, but they do not break anything either.

I don't see an automatical need to add features. Featuritis is a disease,
not a benefit. It limits the room (and increases the work needed) to add
features that are really needed, because of implementation complexity and
backwards compatibility concerns

> > What is the function of being able to add methods to records?
> 
> Not much, I agree, given the existence of objects. It would be better to
> do that instead of introducing 'object' keyword, but that decision was
> made back in the days of Borland Pascal.

(there is some discussion that borland actually did this to limit the scope
of duck typing that is used for for..in and operator overloading. I never
studied that in detail)

> > What is the real use of duplicating const type and var as nested variants
> > inside classes?
> 
> Namespace management.

They copied it from languages that have class as the only namespace. However
the unit based Pascal concept already has units and the unit namespace to
identify between similarly global symbols.

So that is not enough reason. At least for me.

> > Have a look at:
> > http://www.stack.nl/~marcov/delphilater.txt
> 
> Thanks, that is interesting discussion. I will post my thoughts on
> that in a separate mail.

I assume you read

http://www.freepascal.org/faq.var#extensionselect

> > The old rule used to be that
> > - it should make something possible that is not doable otherwise.
> 
> Like strict private/protected?

No. Because every feature makes something doable. IOW look less to the
code-construct but more to what you want to do with it.

Personally I don't believe in micromanagement of visibility levels, and even
if I did, I wanted a more dynamic way to do this (C# afaik goes more that way with
the possibility to tag functions using user defined properties), instead of
ad-hoc expanding visibility specifiers.

> > - _or_ it should be a construct that is used so much that timesavings are
> > ??noticable
> 
> Like for ... in?

I never used in under Delphi except to iterate over sets.

> > And string-case for my feeling belongs in neither. It is just about racking
> > up bullet lists in language wars.
> 
> Well, there is another important design principle. It is sometimes called
> "orthogonality" -- it means that existing language features can be
> combined in any way, with as little limitation as possible.

Yes. But since this is not a simple type, but a complex type, it goes to a
different class. If that is your argument, make sure it works for arrays, records,
classes, interfaces and the other complex types too.

> Since string was introduced as built-in "scalar" type with defined
> equality, lack of 'case' support can be viewed as a design bug.

I don't see string as a scalar type. It is an array or complex type IMHO.