[Lazarus] Easiest way to "case" strings

[Alexander Klenin]

On Thu, Mar 26, 2009 at 00:23, Marco van de Voort <marcov at stack.nl> wrote:
>
> Since we are close to 20 stringtypes + conversions now, I doubt that this is
> really the problem.

Yes, I agree that the string types in FPC are a mess,
and judging by recent discussion, they are planned to became worse.
It is fortunate that Lazarus introduces a little bit of sanity here.

> What problem does "for in" really solve?

Lack of 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. I agree that these are
not a big deal,
and FPC can live without them quite fine, but they do not break anything either.

> 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.

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

Namespace management.

> 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.

> The old rule used to be that
> - it should make something possible that is not doable otherwise.

Like strict private/protected?

> - _or_ it should be a construct that is used so much that timesavings are
>  noticable

Like for ... in?

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

-- 
Alexander S. Klenin