Proposed class READABLE_STRING

[Colin Adams-3]

Attached here is a replacement for STRING_GENERAL, plus the new class
READABLE_STRING, from which it descends.

This has been tested with both GEC and ISE 6.2.7.3489 (by running the
entire Gobo test suite).

If it is possible I would appreciate a decision in principle as to
whether or not to accept this scheme, before Friday.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Peter Gummer-2]

Colin Adams wrote:
> Attached here is a replacement for STRING_GENERAL, plus the new class
> READABLE_STRING, from which it descends.

Colin, how come is_immutable is not redefined?

I note that it is not referenced in either of these classes.

- Peter


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Colin Paul Adams]

>>>>> "Peter" == Peter Gummer <[hidden email]> writes:

    Peter> Colin Adams wrote:
    >> Attached here is a replacement for STRING_GENERAL, plus the new
    >> class READABLE_STRING, from which it descends.

    Peter> Colin, how come is_immutable is not redefined?

    Peter> I note that it is not referenced in either of these
    Peter> classes.

It's redefined in ST_STRING, a fast Unicode string class (shared
substrings) that I am developing in Gobo to try to cure performance
problems in gexslt.

And it could also be changed if Manu were ever to take up the
suggestion he made on adding a bit internally to STRING_32.
--
Colin Adams
Preston Lancashire

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Peter Gummer-2]

Colin Paul Adams wrote:
>
>    Peter> Colin, how come is_immutable is not redefined? ...
>
> It's redefined in ST_STRING, a fast Unicode string class (shared
> substrings) that I am developing in Gobo to try to cure performance
> problems in gexslt.
>
> And it could also be changed if Manu were ever to take up the
> suggestion he made on adding a bit internally to STRING_32.

Ok, so is_immutable is False in READABLE_STRING, despite the absence of
commands, on the assumption that most descendants will be mutable, because
mutable strings are the status quo. Classes of the future, such as ST_STRING
(and, some of us are hoping, STRING_32), will redefine it to True.

Not sure how you're using it, Colin, but it sounds like a potentially useful
query to me.

- Peter



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Colin Paul Adams]

>>>>> "Peter" == Peter Gummer <[hidden email]> writes:

    Peter> Ok, so is_immutable is False in READABLE_STRING, despite
    Peter> the absence of commands, on the assumption that most
    Peter> descendants will be mutable, because mutable strings are
    Peter> the status quo. Classes of the future, such as ST_STRING
    Peter> (and, some of us are hoping, STRING_32), will redefine it
    Peter> to True.

    Peter> Not sure how you're using it, Colin, but it sounds like a
    Peter> potentially useful query to me.

I'm not using it.
I just have the vague feeling that it might be useful to clients
(perhaps a more efficient algorithm can by used for mutable strings in
some cases).
In any case, immutability is an important feature, so it deserves a
query.
--
Colin Adams
Preston Lancashire

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Ted [ES]]

Doesn't it mean a WRITABLE_STRING makes sense too?

BTW: The attached two classes both inherit from STRING_HANDLER.

Ted

>Attached here is a replacement for STRING_GENERAL, plus the new class
>READABLE_STRING, from which it descends.
>
>This has been tested with both GEC and ISE 6.2.7.3489 (by running the
>entire Gobo test suite).
>
>If it is possible I would appreciate a decision in principle as to
>whether or not to accept this scheme, before Friday.
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Microsoft
>Defy all challenges. Microsoft(R) Visual Studio 2008.
>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>_______________________________________________
>freeelks-devel mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/freeelks-devel
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Colin Paul Adams]

>>>>> "Tao" == Tao Feng <[hidden email]> writes:

    Tao> Doesn't it mean a WRITABLE_STRING makes sense too?  BTW: The

STRING_GENERAL is writable.

    Tao> attached two classes both inherit from STRING_HANDLER.

That's just a marker class.
--
Colin Adams
Preston Lancashire

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Ted [ES]]

>
>    Tao> Doesn't it mean a WRITABLE_STRING makes sense too?  BTW: The
>
>STRING_GENERAL is writable.

The point is I don't quite understand why extracting a READABLE_STRING but not a WRITABLE_STRING?

Ted



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Peter Gummer-2]

Tao Feng wrote:
>
> The point is I don't quite understand why extracting a
> READABLE_STRING but not a WRITABLE_STRING?

I think the point is that the concept of a read-only string makes sense, but
a write-only string would be pointless. All strings are readable; I imagine
that's why Colin has elevated it up near the top of the string class
hierarchy. The idea of inheriting from a WRITABLE_STRING class would make
sense too, but in a wholly different way: maybe as a mix-in class or as a
marker class; it certainly wouldn't occupy the central position that Colin
has granted his READABLE_STRING.

Colin is trying to solve the problem of how to have immutable strings in
Eiffel. A WRITABLE_STRING class would not contribute to solving this
problem, would it?

- Peter




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Emmanuel Stapf]

Hi Colin,

Eric and I had a discussion regarding your READABLE_STRING proposal.
Although it addresses the performance issue with substring it would not cope
very well with existing code. For example:

s: READABLE_STRING

io.put_string (s)

would simply cause a conversion of `s' to STRING_8 and the memory benefit is
lost.

Instead, we came up with the following hierarchy:

deferred class READABLE_STRING_GENERAL
end

deferred class STRING_GENERAL
inherit
        READABLE_STRING_GENERAL
end

deferred class READABLE_STRING_8
inherit
        READABLE_STRING_GENERAL
end

deferred IMMUTABLE_STRING_GENERAL
inherit
        READABLE_STRING_GENERAL
end

class STRING_8
inherit
        READABLE_STRING_8
        STRING_GENERAL
end

class IMMUTABLE_STRING_8
inherit
        READABLE_STRING_8
        IMMUTABLE_STRING_GENERAL
end

The same for STRING_32.

The benefit is that it does not break existing code, and in order to use
IMMUTABLE_STRING_8 efficiently in FreeELKS, it would be enough to use
READABLE_STRING_8 whenever a STRING_8 was expected and guaranteed to not be
modified. That way there is no more conversion involved.

The only negative aspects of IMMUTABLE_STRING_8 is that a descendant of this
class could add some routines modifying the content of the string. A
solution would be to mark that class `frozen' but that would prevent someone
to add its own descendant in case IMMUTABLE_STRING_8 is missing some
functionality. Therefore we leave it as is (i.e. not frozen) and will put a
warning in the indexing clause to clearly state the danger of inheriting
from IMMUTABLE_STRING_8.

Regards,
Manu



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Colin Adams-3]

Franck and I have already discussed the frozen possibility, and came
to the same conclusion as you did.

What will the feature contents of immutable_string_general be?

2008/6/3 Emmanuel Stapf [ES] <[hidden email]>:

> Hi Colin,
>
> Eric and I had a discussion regarding your READABLE_STRING proposal.
> Although it addresses the performance issue with substring it would not cope
> very well with existing code. For example:
>
> s: READABLE_STRING
>
> io.put_string (s)
>
> would simply cause a conversion of `s' to STRING_8 and the memory benefit is
> lost.
>
> Instead, we came up with the following hierarchy:
>
> deferred class READABLE_STRING_GENERAL
> end
>
> deferred class STRING_GENERAL
> inherit
>        READABLE_STRING_GENERAL
> end
>
> deferred class READABLE_STRING_8
> inherit
>        READABLE_STRING_GENERAL
> end
>
> deferred IMMUTABLE_STRING_GENERAL
> inherit
>        READABLE_STRING_GENERAL
> end
>
> class STRING_8
> inherit
>        READABLE_STRING_8
>        STRING_GENERAL
> end
>
> class IMMUTABLE_STRING_8
> inherit
>        READABLE_STRING_8
>        IMMUTABLE_STRING_GENERAL
> end
>
> The same for STRING_32.
>
> The benefit is that it does not break existing code, and in order to use
> IMMUTABLE_STRING_8 efficiently in FreeELKS, it would be enough to use
> READABLE_STRING_8 whenever a STRING_8 was expected and guaranteed to not be
> modified. That way there is no more conversion involved.
>
> The only negative aspects of IMMUTABLE_STRING_8 is that a descendant of this
> class could add some routines modifying the content of the string. A
> solution would be to mark that class `frozen' but that would prevent someone
> to add its own descendant in case IMMUTABLE_STRING_8 is missing some
> functionality. Therefore we leave it as is (i.e. not frozen) and will put a
> warning in the indexing clause to clearly state the danger of inheriting
> from IMMUTABLE_STRING_8.
>
> Regards,
> Manu
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> freeelks-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freeelks-devel
>
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Peter Gummer-2]

Some javascript/style in this post has been disabled (why?)

Colin Adams wrote:

> Franck and I have already discussed the frozen possibility, and came
> to the same conclusion as you did.

How about an invariant in IMMUTABLE_STRING_8?

This class hierarchy is very elaborate. I need a picture of it. I think the scariest thing about it on first viewing, however, is the verbosity of the topmost class name, READABLE_STRING_GENERAL. How about calling it STRING_ANY? Then the hierarchy would be:


       STRING_GENERAL<---------------.
            |                        |--STRING_8/32
STRING_ANY<-|-READABLE_STRING_8/32<--:
            |                        |--IMMUTABLE_STRING_8/32
       IMMUTABLE_STRING_GENERAL<-----'

- Peter

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Colin Adams-3]

2008/6/4 Peter Gummer <[hidden email]>:
> Colin Adams wrote:
>
>> Franck and I have already discussed the frozen possibility, and came
>> to the same conclusion as you did.
>
> How about an invariant in IMMUTABLE_STRING_8?

How is it supposed to help?

You can't put an invariant in to say that the data is unchanged after
initialization, unless you keep a copy of that data. It would be fine
if you could only copy the data when invariant checking was enabled,
but I don't know how this could be done.

> This class hierarchy is very elaborate. I need a picture of it. I think the
> scariest thing about it on first viewing, however, is the verbosity of the
> topmost class name, READABLE_STRING_GENERAL. How about calling it

I was thinking that ALL of the names are too verbose. I don't think
any class except STRING_GENERAL needs GENERAL in it.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Colin Paul Adams]

>>>>> "Colin" == Colin Adams <[hidden email]> writes:

    Colin> What will the feature contents of immutable_string_general
    Colin> be?

I hear no answer.

What is the timetable/implementation plan for this scheme?

    Colin> 2008/6/3 Emmanuel Stapf [ES] <[hidden email]>:
    >> Hi Colin,
    >>
    >> Eric and I had a discussion regarding your READABLE_STRING
    >> proposal.  Although it addresses the performance issue with
    >> substring it would not cope very well with existing code. For
    >> example:
    >>
    >> s: READABLE_STRING
    >>
    >> io.put_string (s)
    >>
    >> would simply cause a conversion of `s' to STRING_8 and the
    >> memory benefit is lost.
    >>
    >> Instead, we came up with the following hierarchy:
    >>
    >> deferred class READABLE_STRING_GENERAL end
    >>
    >> deferred class STRING_GENERAL inherit READABLE_STRING_GENERAL
    >> end
    >>
    >> deferred class READABLE_STRING_8 inherit
    >> READABLE_STRING_GENERAL end
    >>
    >> deferred IMMUTABLE_STRING_GENERAL inherit
    >> READABLE_STRING_GENERAL end
    >>
    >> class STRING_8 inherit READABLE_STRING_8 STRING_GENERAL end
    >>
    >> class IMMUTABLE_STRING_8 inherit READABLE_STRING_8
    >> IMMUTABLE_STRING_GENERAL end
    >>
    >> The same for STRING_32.
    >>
    >> The benefit is that it does not break existing code, and in
    >> order to use IMMUTABLE_STRING_8 efficiently in FreeELKS, it
    >> would be enough to use READABLE_STRING_8 whenever a STRING_8
    >> was expected and guaranteed to not be modified. That way there
    >> is no more conversion involved.
    >>
    >> The only negative aspects of IMMUTABLE_STRING_8 is that a
    >> descendant of this class could add some routines modifying the
    >> content of the string. A solution would be to mark that class
    >> `frozen' but that would prevent someone to add its own
    >> descendant in case IMMUTABLE_STRING_8 is missing some
    >> functionality. Therefore we leave it as is (i.e. not frozen)
    >> and will put a warning in the indexing clause to clearly state
    >> the danger of inheriting from IMMUTABLE_STRING_8.
    >>
    >> Regards, Manu
    >>
    >>
    >>
    >> -------------------------------------------------------------------------
    >> This SF.net email is sponsored by: Microsoft Defy all
    >> challenges. Microsoft(R) Visual Studio 2008.
    >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
    >> _______________________________________________ freeelks-devel
    >> mailing list [hidden email]
    >> https://lists.sourceforge.net/lists/listinfo/freeelks-devel
    >>
    >>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
    Colin> Defy all challenges. Microsoft(R) Visual Studio 2008.
    Colin> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
    Colin> _______________________________________________
    Colin> freeelks-devel mailing list
    Colin> [hidden email]
    Colin> https://lists.sourceforge.net/lists/listinfo/freeelks-devel


--
Colin Adams
Preston Lancashire

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel