FreeLists / openbeosstorage / [openbeosstorage] Re: My Usual Confusion

[Tyler Dauwalder <tyler@xxxxxxxxxxxxx>]

> > > Mmh,
> > > maybe introducing a SetType() (or a boolean flag for Initialize())
> > > might
> > > not be such a good idea. Perhaps the standard Initialize() plus a
> > > CreateChild() taking a partition type is fine for the userland 
> > > API.
> > > The
> > > partition module needs to offer functionality for setting the
> > > partition
> > > type in any case, though.
> > 
> > I think I'd rather see that functionality left in. What if some 
> > other
> > OS sets your partition type incorrectly?
> >
> > > Due to getting rid of ContentType(), what can happen, if we 
> > > provide
> > > a
> > > SetType() is, that, if you e.g. invoke SetType("FAT 32 
> > > Filesystem")
> > > on a
> > > BFS formatted partition, the Type() will afterwards still be the
> > > same.
> > 
> > i.e still "BFS"? That seems okay to me. If the user does something
> > like
> > that, they very well ought to have a good reason, or they get what's
> > coming to them.
> 
> You mean, like they set the type, but it apparently remains the same? 
> I
> would in fact be a little confused, if that happened -- probably
> thinking, that the program screwed it up. :-)

Well, the confusion comes from the naming. You're not really setting 
Type() in that instance, you're setting the PartitionType() or whatever 
you want to call it. So if we had a SetPartitionType() that updated the 
PartitionType() to be Fat32, but did not alter the Type(), I would be 
okay with that. (I know you don't like the PartitionType() naming; see 
below :-)

> > I just don't feel it's our place to rule out the
> > possiblity they might in fact have a good reason.
> 
> That's what I think, too.
> 
> > > Mmh, maybe, the Type()+ContentType() approach is not that bad 
> > > after
> > > all?!
> > > Consistency between the two could still be enforced on
> > > initialization, but
> > > we can also have a SetType() that doesn't confuse the user. IIRC
> > > the
> > > only
> > > argument against representing both types was, that we'll often 
> > > have
> > > reduncancy. Which I could easily live with...
> > 
> > Well, as long as the reason from bringing it back is simply to make
> > partition type info fully accessible.
> 
> That's the idea. :-)

I'm okay with it then. :-)

> > I think the Type() to disk system
> > module relationship should still exist and be the main method of
> > determining which disk system to use for a given partition.
> 
> A ContentType() to disk system relationship will still exist. For
> Type() it won't always work, due to types like `Linux', whose
> partitions are supposed to contain any out of quite a bunch of file
> systems. That aside, there's also little reason to find a disk system
> for Type().

Sorry, I was referring to the ContentType() version of Type(), not the 
PartitionType() version of Type(). :-)

> > And how about SetPartitionType()/PartitionType() along with the
> > current
> > Type() instead of the old naming method? I'd rather the more
> > important
> > one have the shorter name, and the partition type is mostly of
> > academic
> > value.
> 
> I follow the reasoning, but you must admit that having
> BPartition::Type() and BPartition::PartitionType() isn't exactly
> intuitive -- unlike Unlike Type()+ContentType(). However, if we rename
> the type related methods, [Content]{Name,Parameters}() should follow
> that naming scheme as well. I've no idea for a suitable name, though.
> Is there something like an opposite of `content'? Er, besides
> `discontent' -- you know what I mean. ;-)

ContainerType()? I can handle ContentType() if a global renaming 
occurs, though.

-Tyler