Re: My Usual Confusion

On Sun, 22 Jun 2003 02:17:18 -0700 Tyler Dauwalder <tyler-cyCl/[email protected]
> wrote:
> 
> On 2003-06-19 at 03:13:59 [-0700], Ingo Weinhold wrote:
> > On Thu, 19 Jun 2003, Tyler Dauwalder wrote:
> > 
> > [...]
> > > > 2) Why not introduce a BPartition::SetType(), that tells the
> > > > partitioning system to set the type of the partition? Or maybe 
> > > > rather
> > > > add a boolean parameter to Initialize() indicating whether to 
> > > > only set
> > > > the partition type or to also let the supplied disk system 
> > > > format 
> > > > its
> > > > contents?
> > >
> > > I think I like the SetType() way better. Initialize(bool) would 
> > > leave
> > > me feeling slightly uneasy that perhaps I got the boolean value
> > > incorrect when I only wanted to change the partition type.
> > 
> > Though, if we aim to enforce consistency between partition type and
> > partition content, setting the type should actually not be allowed.
> 
> Is this really necessary though? Certainly we should make it easy for 
> matching types to be assigned, but I don't know that it needs to be 
> strictly enforced to the point of disallowing the partition type to 
> be 
> changed if desired.

OK.

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

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

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

CU, Ingo