Re: astyle issues

I now have a simple patch for the bitfields issue. It turned out astyle
misread bitfield definitions as labels..

The "block" issue is not yet identified, but is not as irritating
either.

Regards
Henrik

sön 2003-02-23 klockan 00.33 skrev Robert Collins:
> On Sun, 2003-02-23 at 02:12, Henrik Nordstrom wrote:
> > Robert Collins wrote:
>
>
> > > I don't think this is a biggy: as we get more OOP, anonymous structs
> > > will dissappear almost completely.
> >
> >
> > Not completely I think. Using anonymous structs is quite handy for
> > grouping related members.
>
> mmmm, in C style coding yes. I'm pretty sure that over time they will
> all go away - and in a sensible fashion.
>
> > Here is a example of a quite recently OOP class:
>
> Please note that this is only 'partly' OOP. It's been factored out from
> the global ACL class, and somewhat refactorded, but there is more that
> can be done:
>
> > class ACLUserData : public ACLData<char const *>
> > {
> > [...]
> > SplayNode<char *> *names;
> >
> > struct
> > {
> >
> > unsigned int case_insensitive:
> > 1;
>
> This flag should go away. Instead the Splay class should be a true
> container that we simply insert, remove and find within. The container
> will be parameterised for case sensitivity, and thus ACLUserData class
> won't know whether it is case sensitive or not. For dumping the config
> I'd like a utility class to store parse-once, forget forever options and
> reduce the duplicated wordlist manipulation - and that class will know
> about the -i.
>
> > unsigned int required:
> > 1;
>
> This option should go away completely. Instead we should replace the
> ACLUserData instance with another that is also derived from ACLData, and
> that implements the behaviour of REQUIRED. That will remove a bunch of
> 'if' clauses in the ACLUserData class.
>
> > }
> >
> > flags;
> >
> > private:
> > static MemPool *Pool;
> > };
> >
> >
> > We could rewrite this to drop any internal grouping of members within
> > classes, but I prefer not.
>
> IMO it's not about dropping the grouping, its that the specific members
> actually control behaviour - and that is almost always a perfect
> scenario for the user of a strategy or state (the insensitive flag), and
> for polymorphism (i.e. ACLRequiredDATA).
>
> Rob

-- 
Henrik Nordstrom <hno@squid-cache.org>
MARA Systems AB, Sweden