launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

On 09/17/2012 04:35 PM, Deryck Hodge wrote:
> I'd like to use information_type for a few reasons.
> 
> 
> **Consistency with other parts of the code**
> 
> It doesn't make sense to me to have different names for things that
> are basically the same concept in our code.  it's simpler and more
> consistent to stick with information_type.  Other devs who come along
> won't have to get their head around how visibility and
> information_type are related, even basically the same, yet somehow
> different.

I am -0 with this. It disagrees with PersonVisibility. Do you want to
replace PersonVisiblity with InformationType too.

InformationType represents the content the content of an artefact.
Projects and teams are not documents/parts. I agree that three of the
enums do work with projects and teams, but two imply the project or team
exists to create maleware or phishing scams. We will not except that.
Projects and team might use a base class or subclass that only contains
the three sensible enums. Otherwise the db and applications needs
constraints to ensure non-sense is not excepted.

As stakeholders do create teams that are intended to be hidden for a
short time, I favour a third enum. We still need to team Lp to purge
data that cannot be made public. I think this is an increase in scope.

> **Milestones and Series will inherit information_type from Product**
> 
> Again, this is about the simpler and consistent approach to just refer
> to the attributes on the artifacts and also on Product by the same
> name.  It's also more directly obvious what's going on if
> milestones/series don't directly implement information_type.  i.e. it
> makes more sense to say Milestone gets it's information_type from
> Product, rather than Milestone infers information_type from
> Product.visibility.

Agreed.

> **The values should be the same numbers**
> 
> For example, we should be able to consistently refer to PROPRIETARY as
> 5, rather than it be 5 for information_type and 3 for visibility when
> working directly in queries.

Teams would need migration then too if you want consistency.

> **Avoiding references to both visibility and information_type in code**
> 
> I'm sure there will be places in code where we'll have to teach the
> code that visibility is like information_type for the sake of that
> code.  Things like the privacy banner come to mind.  Why not just
> consistently refer to information_type, rather than all the `if
> visibility == PROPRIETARY or information_type == PROPRIETARY`
> constructions?  Simple to work around, I know, but it does equate to
> more code.  I think being consistent with information_type makes the
> code simpler, smaller, and easier to maintain.

+1


-- 
Curtis Hovey
http://launchpad.net/~sinzui

Attachment: signature.asc
Description: OpenPGP digital signature