corelinux-public — General discussions of CoreLinux++

[Corelinux-public] Checked-in

[Frank V. C. <fr...@co...>]

I updated the web with the recent AbstractFactory and Iterator changes.
I checked in AbstractFactory and example code implementation
I checked in Iterator derivations

I am working on documentation updates for Patch Manager and the CVS tree
archive access (index.html, clfaq.html) and when I finish those I will
create 0.4.6. Probably sometime today (I know, I just said monday) but I
need to spend my Sunday on the paying job.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-public] AbstractFactory and Iterator models updated

[Frank V. C. <fr...@co...>]

Iterator needed a AssociativeIterator for use cases where the underlying
implementation has such.

Because this was useful (I wonder what drove what here) I incorporated
into AbstractFactory. In addition, AbstractFactory was type bound with
Identifier where it is up to the implementation to make that decision as
well as the management of the Allocators.

Code for AbstractFactory is being tested now, I am using the MazeFactory
example although it is fairly week.

I am planning to have 0.4.6 go out the door (wire) by Monday.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-public] Patch Manager Usage

[Frank V. C. <fr...@co...>]

I suspect anyone who has a Source Forge user id saw the not about the
Patch Manager thing. I guess CoreLinux++ will use this as described. 

If you don't want to get as deeply involved as becoming a team member,
but you have a fix, example, or addition for consideration then the PM
will be the place to do it!

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] AbstractFactory again...

[Frank V. C. <fr...@co...>]

Joe Nelson wrote:
> 
> > Can I get a amen?
> 
> I'd give you a yay or nay if I knew more about that pattern. I better go
> stick my nose into the design patterns book again... :}
> 
> --Joe
> 

Keep in mind that many of the patterns are not derived from some tool
kit of pattern types but are declared in the problem domain. What my
intention has been, for the types we have so far implemented, is to make
it easier for implementations without the redundancy, thereby increasing
reusability and reasoning capabilities.

Given that as a premise, what would you want from a pattern abstraction?
Would it be full implementation? Would it be partial with domain
derivation capability? A rhetorical question but one meant to elicit the
difficulty in making a class library design decision.

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] AbstractFactory again...

[Joe N. <3ne...@pr...>]

> Can I get a amen?

I'd give you a yay or nay if I knew more about that pattern. I better go
stick my nose into the design patterns book again... :}

--Joe

[Corelinux-public] AbstractFactory

[Frank V. C. <fr...@co...>]

My view change of the previous post came from the proposition that Joe
made in the toolbox thread.
-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-public] AbstractFactory again...

[Frank V. C. <fr...@co...>]

Upon further consideration the change yesterday:

                               1     uses >     1.*
AbstractFactory[key:Identifier]<>----------------->Allocator
                                     -theAllocators

this UML implies that the AF has a collection Allocators.

While this works, it also implies a keyed association (e.g. std::map)
which I was going to happily implement. I don't think that is desirable
in light of the fact that as a class library we would better serve
users/developers by allowing them their choice of allocator storage once
the derive to their problem domain.

Therefore I am recommending we take out the association at AF and
provide a implementationClass stereotype in the diagram that shows a
association without semantics, then AbstractFactory becomes abstract
with pure virtual get, set, remove protected methods.

Can I get a amen?

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-public] AbstractFactory design updated

[Frank V. C. <fr...@co...>]

I updated the design because:

The original had

AbstractFactory<>---------->AbstractAllocator<class TypeImpl>

Which constrained the flexibility because in the implementation the
collection, by this definition, would only allow a collection of
homogenous type allocators because

class AbstractFactory
{
public:

	void addAllocator( AbstractAllocator<TYPE NEEDED> * );
};

So, a base class Allocator was inserted which AbstractAllocator derives
from.

This allows the AbstractFactory interface to ignore instantiated
template constraints and focus on managing the Allocators regardless of
type.

The intent is that a AbstractFactory supports creation services for more
than one type, given the GoF example:

class FactoryImplementation
{
public:

	WallPtr	createWall();
	DoorPtr createDoor();
	...
};

which in the new design the declaration would be:

class WallAllocator : public AbstractAllocator<Wall> {}
class DoorAllocator : public AbstractAllocator<Door> {}

class RoomFactory : public AbstractFactory
{
public:

		RoomFactory( void );

	WallPtr	createWall( void );
	DoorPtr	createDoor( void );
};

with an implementation like:

RoomFactory::RoomFactory( void )
{
   addAllocator( new WallAllocator( WallIdentifier ) );
   addAllocator( new DoorAllocator( DoorIdentifier ) );
}

WallPtr RoomFactory::createWall( void )
{
   WallPtr aWall( NULLPTR );
   aWall = getAllocator( WallIdentifier )->createObject();

   CHECK( aWall != NULLPTR );

   return aWall;
}

and so on for Door, Window, etc.

Anyone?

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] Joes "toolbox" programming straw man

[Frank V. C. <fr...@co...>]

> > I received this from Joe although I believe his intention was to
float
> > by us all.
>
> Yeah, I accidentally had "corelinux" set to the wrong address in my
> address book. Thanks for passing it along. What do you think about it?
> Why did you label it a straw man?
>
> --Joe

I like it. My background covers some of the "dynamic" aspect of my
response to it on the mailing list.

I meant no offense about "straw man" as, and I believe I was somewhat
correct, you were tossing it into the wind to see if it floats. No?

---
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] Re: Joes "toolbox" programming straw man

[Frank V. C. <fr...@co...>]

[snip]
> > The computer then looks through
> > whatever collection classes it has, and finds one that matches these
> > specs. If it can't find one, it throws an exception and perhaps even
> > makes a recommendation for the next-best class that is available in
> > its toolbox.
> > This way, programmers' toolboxes could be filled from classes
> > off the net, and the computers would be responsible for making a
match
> > between what a programmer requests in his program, and what his
> > toolbox actually holds.
> >
> > The idea gets powerful when you start to consider the whole
computer,
> > hardware and software, as items in a toolbox. Wouldn't it be nice to
> > ask the computer for a soundcard tool in the box, and specify that
you
> > want one that has wavetable MIDI synthesis, if possible?
> >
> > The whole idea rests of finding the correct tool hierarchy and being
> > able to quantitatively assign fitness values to certain operations
on
> > those classes. Several types of class operations lend themselves
> > especially well to this quantitative rating, as was demonstrated by
> > the example of the collections' operations being rated by
>>  algorithmic complexity.
>>  I think numerical hardware capabilities like screen
> > resolution, duplex capabilities in soundcards, and printer speed
also
> > are perfect candidates for "toolboxing." I've seen this idea of
> > requesting capabilities before in Microsoft's DirectX, but its
> > application across the whole hardware/software spectrum is what
seems
> > novel to me.
> >
> > So is this idea so old that Knuth taught it to his dinosaurs? Does
it
> > have any merit?
> >
> > --Joe Nelson

I like it.

From a static standpoint, where the developer chooses at development
time objects based on some characteristics, it is as easy as
specification detail reading and understanding their problem domain
requirements. And of course the classes that fill those requirements.

From a dynamic standpoint, I don't know about dinosaurs but your idea
crosses a couple of area borders both old and new. The following are
those areas which you are bringing into play, I can further describe
them if anyone wants.

1. Resource loading - needs -
2. Resource monitoring
3. Dynamic Configuration -needs-
4. Constraint solving
5. Registration and resolution

This is a more complex approach, and because of that even more
interesting.

Re: [Corelinux-public] Joes "toolbox" programming straw man

[Joe N. <3ne...@pr...>]

> I received this from Joe although I believe his intention was to float
> by us all.

Yeah, I accidentally had "corelinux" set to the wrong address in my
address book. Thanks for passing it along. What do you think about it?
Why did you label it a straw man?

--Joe

[Corelinux-public] Re: Joes "toolbox" programming straw man

[Frank V. C. <fr...@co...>]

I received this from Joe although I believe his intention was to float
by us all.

> Just recently I got an idea about a new way (at least it's new to me)
of
> designing a C++ framework. It's based on the toolbox metaphor that
I've
> heard applied to software components. The easiest way for me to
contrast
> this new design with current systems is by an example.
>
> Currently, if a programmer wants to use a C++ collection class, they
> think in terms of arrays, linked lists, stacks, queues, etc. They
select
> the right one for their needs based on the speed tradeoffs of its
method
> functions. Fundamentally, these abstractions do the same thing: store
a
> pile of related data. A programmer thinking in terms of the toolbox
will
> see these abstractions all as a type of hammer, a collection hammer.
> This idea of subclassing is nothing new; what is new is the way this
> programmer selects a collection "hammer" from the toolbox. The
> programmer thinks about the problem at hand, and makes his speed
> tradeoffs explicit.
>
> Let's say that the programmer wants a collection "hammer" that is
> optimized for insertion and deletion of data items. Rather than just
> instantiating a linked list, he asks the computer for a collection
type.
> He specifies that he needs an average random access time of O(n/2), a
> worst-case random-access of O(n), and a constant insertion/deletion
> time. (By the way, I don't know if these values are realistic --
they're
> just for the sake of explanation.) The computer then looks through
> whatever collection classes it has, and finds one that matches these
> specs. If it can't find one, it throws an exception and perhaps even
> makes a recommendation for the next-best class that is available in
its
> toolbox. This way, programmers' toolboxes could be filled from classes
> off the net, and the computers would be responsible for making a match
> between what a programmer requests in his program, and what his
toolbox
> actually holds.
>
> The idea gets powerful when you start to consider the whole computer,
> hardware and software, as items in a toolbox. Wouldn't it be nice to
ask
> the computer for a soundcard tool in the box, and specify that you
want
> one that has wavetable MIDI synthesis, if possible?
>
> The whole idea rests of finding the correct tool hierarchy and being
> able to quantitatively assign fitness values to certain operations on
> those classes. Several types of class operations lend themselves
> especially well to this quantitative rating, as was demonstrated by
the
> example of the collections' operations being rated by algorithmic
> complexity. I think numerical hardware capabilities like screen
> resolution, duplex capabilities in soundcards, and printer speed also
> are perfect candidates for "toolboxing." I've seen this idea of
> requesting capabilities before in Microsoft's DirectX, but its
> application across the whole hardware/software spectrum is what seems
> novel to me.
>
> So is this idea so old that Knuth taught it to his dinosaurs? Does it
> have any merit?
>
> --Joe Nelson


---
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] while i'm on the topic of multi-threading...

[Frank V. C. <fr...@co...>]

> have you considered implementing monitors?  (Hoare monitors
> or the like)  seems a valid consideration if you plan to implement the
Base
> CoreLinux class
(https://sourceforge.net/forum/message.php?msg_id=4954)
> and a natural amalgum of OO and multi-threading principles.
>
> or has this been ruled out altogether?
>
> reasons? thoughts?

Yes, we need to bring this issue back to life. There are a couple of
monitor methodologies (Mesa, Hoare, etc) that should be looked into. I
have used Hoare before <no pun> because of it's predictability, but its
an open issue.

Here is a post I made to the mailing list sometime back:

While thinking about the reference count requirement it occurred to be
that we should deal with an important issue up front:

As an example, lets assume we have a reference class that has the
behavior of incrementing a count as long as additional constructs
(through copy constructor or assignment) are read-only. The question is,
should the state changes in the Reference class be protected by a mutual
exclusion semaphore? If so, a) is it one (1) semaphore for all
instances? b) One semaphore per instance? c) Shared pools of semaphores
(Flyweight pattern) shared by the Reference class?

Each has their pros and cons (simplified):

Pros A: Small memory ( one semaphore for the class )
Cons A: Low degree of concurrency ( only one access at a time )

Pros B: High degree of concurrency ( only references to the same object
blocked )
Cons B: Large memory, possible semaphore exhaustion

Pros C: High degree of concurrency ( See Pros B )
Cons C: More code and memory to manage pools ( maps, indirection,
extents, etc. )

The same applies to other types we have waiting in the wings.

---
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-public] while i'm on the topic of multi-threading...

[Jacob C. <jac...@ho...>]

have you considered implementing monitors?  (Hoare monitors
or the like)  seems a valid consideration if you plan to implement the Base
CoreLinux class (https://sourceforge.net/forum/message.php?msg_id=4954)
and a natural amalgum of OO and multi-threading principles.

or has this been ruled out altogether?

reasons? thoughts?

Re: [Corelinux-public] Re: Class Library and Framework Requirements forum msg #7915 (Threads)

[Jacob C. <jac...@ho...>]

>"Frank V. Castellucci" wrote:

[snip]
>I think we have two options:
>
>One-to-One : Uses the Linux "clone" api which is more efficient than
>fork. I perceived that clone, even though it calls it a process in the
>'ps' display, is still running in the address space of the parent and
>they share the memory space. Thread n modifies something and it is
>visible to the other threads or main process thread.
>
>Many-to-Many : Combo of "clone" and a homegrown scheduler that takes its
>que from the kernel.
>
>I believe the latter to be an expensive (time, resources, acceptance)
>proposition but attractive none the less.


for performance reasons i presume? (referring to attractiveness)

we may be able to mitigate some of the time necessary for the many-to-many
implementation by taking a look at the scheduling code for GNU Pth.  I think
it is
under the GPL so we can't cut'n'paste but taking a look i think would be
useful.


>If we think foward to the frameworks endeavor, it is reasonable to
>construct a Thread or Process framework that can be used to serve up
>default libcorelinux++ Thread (one-to-one) or whatever the framework
>extension desires (many to many, etc.).


i agree.  this would leave the door open for a many-to-many implementation
with a readily useable one-to-one implementation.

Re: [Corelinux-public] Re: Class Library and Framework Requirements forum msg #7915 (Threads)

[Frank V. C. <fr...@co...>]

"Frank V. Castellucci" wrote:
> 
> Jacob,
> 
> Could you clarify one-to-one, one-to-many, and many-to-many?
> 
> Thanks
> --

"before he read the LinuxThreads article."

I think we have two options:

One-to-One : Uses the Linux "clone" api which is more efficient than
fork. I perceived that clone, even though it calls it a process in the
'ps' display, is still running in the address space of the parent and
they share the memory space. Thread n modifies something and it is
visible to the other threads or main process thread.

Many-to-Many : Combo of "clone" and a homegrown scheduler that takes its
que from the kernel. 

I believe the latter to be an expensive (time, resources, acceptance)
proposition but attractive none the less.

If we think foward to the frameworks endeavor, it is reasonable to
construct a Thread or Process framework that can be used to serve up
default libcorelinux++ Thread (one-to-one) or whatever the framework
extension desires (many to many, etc.).


-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] Re: Class Library and Framework Requirements forum msg #7915 (Threads)

[Frank V. C. <fr...@co...>]

Jacob Christen wrote:
> 
> Relevant forum message links:
> https://sourceforge.net/forum/message.php?msg_id=7915
> https://sourceforge.net/forum/message.php?msg_id=7870
> 
> Frank asked me to bring up my post to this forum concerning threads
> (https://sourceforge.net/forum/message.php?msg_id=7870).  After re-
> reading it I am surprised I forgot to include a relevant link that
> I didn't quite reference in my post but was presenting food for thought
> based upon it:
> http://www-4.ibm.com/software/developer/library/java2/index.html.
> 
> A quick summary of my thoughts:
> Frank has said that he wishes to go "right to the metal" for threading
> support.  To me this means overlooking the good pthreads
> implementation that is available for linux (glibc-linuxthreads) and
> writing our own.  Keeping the above IBM article in mind, we have
> three options for implementation:
> 1)  one-to-one -- why bother as this is currently supported by the
> available posix threads implementation
> 2)  one-to-many -- two things:  there is already a pthread-compatible
> implementation of userland-scheduled threads (GNU Pth) AND this
> model will absolutely not make use of SMP systems.
> 3) many-to-many -- this hasn't been done yet for linux and to me is
> the most exciting prospect (as well as the most difficult) and would
> greatly benefit the project and the linux development community in
> general.  problem is this means writing our own scheduler with
> the added burden of insuring that context switches on mutex and
> conditional operations are MORE efficient than what is currently
> done in the kernel (I've not delved into the kernel code so this
> may be relatively easy to achieve or not).
> 
> Given these options, I feel we really only have one choice to make:
> Do we want to use the current posix threads implementation to support
> our multi-threading classes or do we instead attempt to implement a
> many-to-many threading model for linux.  I favor the latter even though
> it is the mroe difficult because we will get better performance when
> it comes time to scale massively upward AND on non-SMP systems.
> 
> What do the rest of you think?
> 
> --
> Jacob

Jacob,

Could you clarify one-to-one, one-to-many, and many-to-many?

Thanks
-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-public] Re: Class Library and Framework Requirements forum msg #7915 (Threads)

[Jacob C. <jac...@ho...>]

Relevant forum message links:
https://sourceforge.net/forum/message.php?msg_id=7915
https://sourceforge.net/forum/message.php?msg_id=7870


Frank asked me to bring up my post to this forum concerning threads
(https://sourceforge.net/forum/message.php?msg_id=7870).  After re-
reading it I am surprised I forgot to include a relevant link that
I didn't quite reference in my post but was presenting food for thought
based upon it:  
http://www-4.ibm.com/software/developer/library/java2/index.html.

A quick summary of my thoughts:
Frank has said that he wishes to go "right to the metal" for threading
support.  To me this means overlooking the good pthreads 
implementation that is available for linux (glibc-linuxthreads) and
writing our own.  Keeping the above IBM article in mind, we have
three options for implementation:
1)  one-to-one -- why bother as this is currently supported by the
available posix threads implementation
2)  one-to-many -- two things:  there is already a pthread-compatible
implementation of userland-scheduled threads (GNU Pth) AND this
model will absolutely not make use of SMP systems.
3) many-to-many -- this hasn't been done yet for linux and to me is
the most exciting prospect (as well as the most difficult) and would
greatly benefit the project and the linux development community in
general.  problem is this means writing our own scheduler with
the added burden of insuring that context switches on mutex and 
conditional operations are MORE efficient than what is currently
done in the kernel (I've not delved into the kernel code so this
may be relatively easy to achieve or not).

Given these options, I feel we really only have one choice to make:
Do we want to use the current posix threads implementation to support
our multi-threading classes or do we instead attempt to implement a 
many-to-many threading model for linux.  I favor the latter even though
it is the mroe difficult because we will get better performance when
it comes time to scale massively upward AND on non-SMP systems.

What do the rest of you think?

--
Jacob

[Corelinux-public] Updates

[Frank V. C. <fr...@co...>]

I posted (web/cvs) the SRSs for all the Creational patterns.
I posted (web/cvs) the Analysis and Design for AbstractFactory
I added  (Bug Tracking) Features for Creational patterns
I added  (Tasks) Analysis, Design, and Implementation tasks for
Creational patterns

As if there wasn't enough process around here <g>, the way I have been
working once the Feature is opened is:

A. Take ownership of Feature with comment: Working on Analysis. Take
ownership of Analysis Task

B. Complete analysis: Mark Analysis Task complete and close, Release
ownership of Feature with comment Analysis complete.

C. Take ownership of Feature with comment: Working on Design. Take
ownership of Design Task

D. Complete design: Mark Design Task complete and close, Release
ownership of Feature with comment Design complete.

E. Take ownership of Feature with comment: Working on Implementation.
Take ownership of Implementation Task

F. Complete implementation: Mark Implementation Task complete and close,
Release ownership of Feature with comment Implementation complete.

G. Release CoreLinux++ X.Y.Z

H. Mark Feature as Fixed and Closed

I. Mark Release X.Y.Z Feature as Fixed and Closed

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

[Corelinux-public] CoreLinux++ 0.4.5 Released

[Frank V. C. <fr...@co...>]

Please excuse me if I already did this but 0.4.5 has been released.

It includes the Facade and Decorator pattern implementations.

To move on the Flyweight and Proxy I felt that I needed to get the
Creational patterns in first as they are better served with factory and
etc.

So, I created features for all of them to get the SRS going. I will chip
them off one at a time, or if anyone is interested to take a whack...

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] String Analysis, Design, Implementation open

[Frank V. C. <fr...@co...>]

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

Re: [Corelinux-public] String Analysis, Design, Implementation open

[Jim K. <jrk...@li...>]

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

[Corelinux-public] Facade test almost there

[Frank V. C. <fr...@co...>]

I thought I would get 0.4.5 out today, but I didn't get the test case
for Facade working until late, and I need to comment the interfaces.

At any rate, what I settled on was:

Object        : Vacuous object with ID
ObjectFactory : Object create, destroy, cache, and ID generator.
Dictionary    : Object name to ID map
Modeler       : Manages Object parent to child relationships

ObjectModel   : The Facade that interfaces to the application for
creating, renaming, deleting, name changes, and relationship creation
and deletion.

I didn't have time to do a C parser <g> like GoF example.

As I am off to the day job, I will complete tonight and CVS it with a
release in the tomorrow morning 

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux

Re: [Corelinux-public] String Analysis, Design, Implementation open

[Frank V. C. <fr...@co...>]

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.

Re: [Corelinux-public] String Analysis, Design, Implementation open

[Frank V. C. <fr...@co...>]

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