[openbeosstorage] Re: My Usual Confusion
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sun, 22 Jun 2003 15:02:55 +0200 CEST
On Sun, 22 Jun 2003 02:17:18 -0700 Tyler Dauwalder <tyler@xxxxxxxxxxxxx
> 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
Other related posts:
