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

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

On Thu, 26 Jun 2003 22:39:55 -0700 Tyler Dauwalder <tyler@xxxxxxxxxxxxx
> wrote:
> > > > 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 :-)

Yes, sure. My original argument assumed, that we would get rid of the 
partition type flavored Type(). If we keep both, then there's no 
problem, of course.

> > > 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. :-)

Ah, oh! :-)

[...]
> > > 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.

Mmh, ContainerType() sounds a bit like the type of the partition's 
container, i.e. its parent partition. Re-thinking it, I actually find 
Type()+ContentType() pretty exact. Even DriveSetup lists the `Partition 
Type' (type of the partition, BPartition::Type()) and the `File System' 
(the type of the partition's content, BPartition::ContentType() -- 
DistSystemType() would be more precise, but is also a bit longer).

Has anyone else an opinion on the extremely complex issue of naming?

CU, Ingo