Menu
▾
▴
corelinux-public
|
From: Frank V. C. <fr...@co...> - 2000-01-22 19:58:29
|
I removed Jim from the Feature (he completed the Requirement) Changed the Feature Status to Open Created Analysis task for String (open) Created Design task for String (open) Created Implementation task for String (open). Unlike the patterns I have been working on, this one has some work to do. Even if no one wants to grab the Analysis bull by the horns, we should at least be discussing aspects of this like the detailed use cases, like the std::basic_string interface where the type can be ignored. I think this is a good chance to flex some of MagicDraw UML as well once we enumerate the use cases. -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux |
|
From: Joe N. <3ne...@pr...> - 2000-01-23 00:20:27
|
> Unlike the patterns I have been working on, this one has some work to > do. Even if no one wants to grab the Analysis bull by the horns, we > should at least be discussing aspects of this like the detailed use > cases, like the std::basic_string interface where the type can be > ignored. I think this is a good chance to flex some of MagicDraw UML as > well once we enumerate the use cases. How about making all strings be unicode? |
|
From: Frank V. C. <fr...@co...> - 2000-01-23 14:59:36
|
Joe Nelson wrote: > > > Unlike the patterns I have been working on, this one has some work to > > do. Even if no one wants to grab the Analysis bull by the horns, we > > should at least be discussing aspects of this like the detailed use > > cases, like the std::basic_string interface where the type can be > > ignored. I think this is a good chance to flex some of MagicDraw UML as > > well once we enumerate the use cases. > > How about making all strings be unicode? > My mail keeps getting whacked. Joe, If we just use Unicode then we either have to use another library, or create one. What we originally proposed was to abstract the interface and then provide some means to let users (developers) adapt another string implementation to our interface. This is more complex but allows 1. For CoreLinux++ we can implement classes that use the String abstraction. This way we are confident (as much as can be) that the developers choice of string implementation won't break us (see Adapter). 2. String implementations that haven't been developed yet to be use later on (ditto Adapter). 3. Dynamic string changes in some cases (see Bridge). -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux http://www.colconsulting.com Object Oriented Analysis and Design |Java and C++ Development |
|
From: Joe N. <3ne...@pr...> - 2000-01-23 15:41:55
|
> If we just use Unicode then we either have to use another library, or > create one. What we originally proposed was to abstract the interface > and then provide some means to let users (developers) adapt another > string implementation to our interface. This is more complex but allows > > 1. For CoreLinux++ we can implement classes that use the String > abstraction. This way we are confident (as much as can be) that the > developers choice of string implementation won't break us (see Adapter). > > 2. String implementations that haven't been developed yet to be use > later on (ditto Adapter). > > 3. Dynamic string changes in some cases (see Bridge). So corelinux++ is only aiming to be an interface, rather than provide any implementations? --Joe |
|
From: Frank V. C. <fr...@co...> - 2000-01-23 15:59:59
|
Joe Nelson wrote:
>
> > If we just use Unicode then we either have to use another library, or
> > create one. What we originally proposed was to abstract the interface
> > and then provide some means to let users (developers) adapt another
> > string implementation to our interface. This is more complex but allows
> >
> > 1. For CoreLinux++ we can implement classes that use the String
> > abstraction. This way we are confident (as much as can be) that the
> > developers choice of string implementation won't break us (see Adapter).
> >
> > 2. String implementations that haven't been developed yet to be use
> > later on (ditto Adapter).
> >
> > 3. Dynamic string changes in some cases (see Bridge).
>
> So corelinux++ is only aiming to be an interface, rather than provide
> any implementations?
>
> --Joe
>
No, we need to at least provide a String derivation that works with
straight char.
For example, lets drop to a implementation for discussion:
AbstractString {abstract}
AbstractStringAdapter {abstract} isA Adapter, isAbstractString
StringUtf8 isA AbstractStringAdapter and hasA std::string
then StringUtf8 delegates to the string implementation when a
AbstractString method is invoked.
Meanwhile, any of our other classes (libcorelinux++, libcoreframework++)
that use a string would use AbstractString and would work with whatever
string( char, wchar, Unicde, etc) was adapted to our interface.
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
|
|
From: Jim K. <jrk...@li...> - 2000-01-24 16:47:43
|
"Frank V. Castellucci" wrote:
> Joe Nelson wrote:
> >
> > > If we just use Unicode then we either have to use another library, or
> > > create one. What we originally proposed was to abstract the interface
> > > and then provide some means to let users (developers) adapt another
> > > string implementation to our interface. This is more complex but allows
> > >
> > > 1. For CoreLinux++ we can implement classes that use the String
> > > abstraction. This way we are confident (as much as can be) that the
> > > developers choice of string implementation won't break us (see Adapter).
> > >
> > > 2. String implementations that haven't been developed yet to be use
> > > later on (ditto Adapter).
> > >
> > > 3. Dynamic string changes in some cases (see Bridge).
> >
> > So corelinux++ is only aiming to be an interface, rather than provide
> > any implementations?
> >
> > --Joe
> >
>
> No, we need to at least provide a String derivation that works with
> straight char.
>
> For example, lets drop to a implementation for discussion:
>
> AbstractString {abstract}
> AbstractStringAdapter {abstract} isA Adapter, isAbstractString
>
> StringUtf8 isA AbstractStringAdapter and hasA std::string
>
> then StringUtf8 delegates to the string implementation when a
> AbstractString method is invoked.
>
> Meanwhile, any of our other classes (libcorelinux++, libcoreframework++)
> that use a string would use AbstractString and would work with whatever
> string( char, wchar, Unicde, etc) was adapted to our interface.
>
> --
> Frank V. Castellucci
> http://corelinux.sourceforge.net
> OOA/OOD/C++ Standards and Guidelines for Linux
>
> _______________________________________________
> Corelinux-public mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-public
I thought we could define the interface in AbstractString, and then create a
CoreLinuxString using the std::string, and the Adapter. This would give us a
functional string class, and provide an example for extension of the
AbstractString into another string class (for use with Unicode or ISO/IEC
10646, etc.).
Jim Koontz
jrk...@us...
|
|
From: Frank V. C. <fr...@co...> - 2000-01-24 18:14:58
|
Jim Koontz wrote:
>
> "Frank V. Castellucci" wrote:
>
> > Joe Nelson wrote:
> > >
> > > > If we just use Unicode then we either have to use another library, or
> > > > create one. What we originally proposed was to abstract the interface
> > > > and then provide some means to let users (developers) adapt another
> > > > string implementation to our interface. This is more complex but allows
> > > >
> > > > 1. For CoreLinux++ we can implement classes that use the String
> > > > abstraction. This way we are confident (as much as can be) that the
> > > > developers choice of string implementation won't break us (see Adapter).
> > > >
> > > > 2. String implementations that haven't been developed yet to be use
> > > > later on (ditto Adapter).
> > > >
> > > > 3. Dynamic string changes in some cases (see Bridge).
> > >
> > > So corelinux++ is only aiming to be an interface, rather than provide
> > > any implementations?
> > >
> > > --Joe
> > >
> >
> > No, we need to at least provide a String derivation that works with
> > straight char.
> >
> > For example, lets drop to a implementation for discussion:
> >
> > AbstractString {abstract}
> > AbstractStringAdapter {abstract} isA Adapter, isAbstractString
> >
> > StringUtf8 isA AbstractStringAdapter and hasA std::string
> >
> > then StringUtf8 delegates to the string implementation when a
> > AbstractString method is invoked.
> >
> > Meanwhile, any of our other classes (libcorelinux++, libcoreframework++)
> > that use a string would use AbstractString and would work with whatever
> > string( char, wchar, Unicde, etc) was adapted to our interface.
> >
>
> I thought we could define the interface in AbstractString, and then create a
> CoreLinuxString using the std::string, and the Adapter. This would give us a
> functional string class, and provide an example for extension of the
> AbstractString into another string class (for use with Unicode or ISO/IEC
> 10646, etc.).
>
> Jim Koontz
> jrk...@us...
I think we said the same thing. Have you given anythough to what the
AbstractString thinks the character types are?
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
|
|
From: Frank V. C. <fr...@co...> - 2000-01-24 06:17:43
|
Joe Nelson wrote: > > > Unlike the patterns I have been working on, this one has some work to > > do. Even if no one wants to grab the Analysis bull by the horns, we > > should at least be discussing aspects of this like the detailed use > > cases, like the std::basic_string interface where the type can be > > ignored. I think this is a good chance to flex some of MagicDraw UML as > > well once we enumerate the use cases. > > How about making all strings be unicode? > Thats why we thought that a String abstraction would be useful, and anyone wanting Unicode or Utf and still use whatever we have could just adapt the string of choice to the CoreLinux++ string. This keeps us from being tied to a particular implementation (see Adapter or Bridge) and being flexible enough so we don't tie the developer down either. -- Frank V. Castellucci |
|
From: Frank V. C. <fr...@co...> - 2000-01-24 06:17:43
|
Joe Nelson wrote: > > > Unlike the patterns I have been working on, this one has some work to > > do. Even if no one wants to grab the Analysis bull by the horns, we > > should at least be discussing aspects of this like the detailed use > > cases, like the std::basic_string interface where the type can be > > ignored. I think this is a good chance to flex some of MagicDraw UML as > > well once we enumerate the use cases. > > How about making all strings be unicode? > My mail keeps getting whacked. Joe, If we just use Unicode then we either have to use another library, or create one. What we originally proposed was to abstract the interface and then provide some means to let users (developers) adapt another string implementation to our interface. This is more complex but allows 1. For CoreLinux++ we can implement classes that use the String abstraction. This way we are confident (as much as can be) that the developers choice of string implementation won't break us (see Adapter). 2. String implementations that haven't been developed yet to be use later on (ditto Adapter). 3. Dynamic string changes in some cases (see Bridge). -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux http://www.colconsulting.com Object Oriented Analysis and Design |Java and C++ Development |
|
From: Frank V. C. <fr...@co...> - 2000-01-24 06:17:43
|
Joe Nelson wrote: > > > Unlike the patterns I have been working on, this one has some work to > > do. Even if no one wants to grab the Analysis bull by the horns, we > > should at least be discussing aspects of this like the detailed use > > cases, like the std::basic_string interface where the type can be > > ignored. I think this is a good chance to flex some of MagicDraw UML as > > well once we enumerate the use cases. > > How about making all strings be unicode? > If this makes it through I will post a follow up. |
