np and thanks!

Alex

On 7/18/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
Posted to the list which was supposed to receive this mail, for some
unknown reasons, I jjust replied to Alex instead of posting the ML.
Was absolutly not my initial intention...

On 7/18/07, Emmanuel Lecharny < elecharny@gmail.com> wrote:
> Hi Alex,
>
> I was looking at the Visitor pattern, and the more I look at it, the
> less I think it is suitable for our need in this special case.
>
> What we have here is a very static tree, with branches and leaves. All
> the leaves are the same (Partitions), and branches are just breanches.
>
> The operations we will use are :
> - lookup
> - add
> - delete
>
> (the last one has not been written yet)
>
> If we have to map those operations to Visitors, then we will have to
> implement three visitors, when we could have simply declared those
> three methods to the main class (PartitionStructure). What I mean is
> that this tree isn't handling different kind of objects, so we don't
> need to use a complex pattern for such a simple intern fonctionality.
>
> I would also add that we should not use patterns for everything : it
> seems to me that many people are considering patterns as a substitute
> to common sense, and are abusing them. I have had this feeling 2 years
> ago on a big project when I had a discussion with someone who thought
> that Design Patterns were the Alpha and Omega of programming. He was
> young (around 27) and was using patterns for everything in his
> program. Of course, his project (one out of the 300 projects we were
> trying to aggregate) was one of the most cripled and fucked up of all
> the projects : nobody was able to handle it because of the overuse of
> patterns... But they were no way to tell him to use patterns when
> needed only : the GoF book was like a Bible to him, and I was seen as
> an apostate to him, deserving to be burnt slowly...
>
> To be clear : Visitor pattern is ok for Normalization, this is almost
> the perfect exemple of good use. We couls also use it for Search. But
> I don't think it's suitable for the Partition tree.
>
> Any other opinion ?
>
> On 7/14/07, Alex Karasulu <akarasulu@apache.org> wrote:
> > Also Emmanuel I'd like to see if we can break out the search (lookup)
> > functionality
> > into a visitor for the tree.  As an example you can look at the way this is
> > done with
> > the filter AST in o.a.d.shared.ldap.filter .  Here a visitor can be
> > responsible for adding
> > new nodes and removing new nodes instead of adding the code to do this into
> > the
> > node classes themselves.
> >
> > WDYT?
> >
> > Alex
> >
> >
> >  On 7/13/07, Alex Karasulu <akarasulu@apache.org> wrote:
> > > Hi Emmanuel,
> > >
> > > The code is solid as a rock.
> > >
> > > I just worked the clarity of it a bit.  Essentially you're building a tree
> > that is
> > > being used as a rapid lookup structure to find partitions corresponding to
> > the
> > > DN of the entries are contained by a partition.  I simply renamed a few
> > things
> > > in commit 556176 to make it clear as to what you're doing or at least what
> > I
> > > think you are doing.  Notice how much more clear it is when I just renamed
> > > the following classes and moved them into an inner package called
> > > o.a.d.s.c.partition.tree :
> > >
> > > PartitionContainer => BranchNode class
> > > PartitionStructure => Node interface
> > > AbstractPartitionStructure => AbstractNode
> > > PartitionHandler => LeafNode
> > >
> > > I hope this was the correct interpretation of what you meant by these
> > names.
> > > Please correct me if I am wrong.
> > >
> > > There still are some things that confuse me like how the lookups are done.
> >  Could
> > > you add some documentation to describe it?  Also it seems you are
> > sometimes using
> > > the partition suffix to check for matching and sometimes using the rdn.
> > Could you
> > > clarify when one is used over the other?  Perhaps breaking up complex
> > statements
> > > which you join together like this below will make it easier to understand:
> > >
> > >             return current.addNode( dn.getRdn( index ).toString(),
> > >                 buildNode( new BranchNode(), dn, index + 1, partition ) );
> > >
> > > Also btw how the index parameter is being used in this recursion is a bit
> > confusing
> > > could you clarify?
> > >
> > > I think this data structure might be better integrated directly into the
> > Partition and
> > > PartitionNexus interfaces.  Right now you use it as an alternative data
> > structure in the
> > > nexus.  Perhaps we could make nexus into a branch node and have it contain
> > other
> > > nexus objects?  Meaning a nexus should be what here is modeled as a
> > BranchNode.
> > > A non-nexus Partition can be the equivalent of a LeafNode.  This way the
> > data structure
> > > is directly integrated into the architecture rather than having it used in
> > as an alternative
> > > data structure just in the nexus.  This way we can gain nested nexus' and
> > use the structure
> > > in an integrated fashion.
> > >
> > > Furthermore I know you dislike "patterns" but please try to use the
> > correct terminology
> > > when you are designing them.  I know you old timers just do patterns
> > without getting
> > > into the jargon of it all but it helps communicate what you are doing
> > better to us newbies.
> > > People understand tree structures and the language associated with them
> > verses things
> > > like PartitionContainer and PartitionHandler.  If this continues I'm going
> > to be totally lost.
> > >
> > > Thanks,
> > > Alex
> > >
> > >
> > > On 7/13/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> > >
> > > > You have my +1 for that !
> > > >
> > > > On 7/13/07, Alex Karasulu < akarasulu@apache.org> wrote:
> > > > > Hi,
> > > > >
> > > > > I'm looking through this code and it's painful especially with the
> > names
> > > > > chosen for the interface,
> > > > > and the implementations.  I'm going to start reworking it a bit so it
> > can be
> > > > > better understood at
> > > > > first glance.
> > > > >
> > > > > Alex
> > > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Cordialement,
> > > > Emmanuel Lécharny
> > > > www.iktek.com
> > > >
> > >
> > >
> >
> >
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com