Time for a little Object-Oriented refactoring? [was Re: Automatic homepage for sourceforge, googlecode, etc.]

[Jordan K. Hubbard]

I hate to get all OOPish on everyone here, but this seems like one of  
those problem spaces that would be well-served by something more  
closely approximating an class model with inheritance and mix-ins than  
the current matrix of options and control flags we have today.  I'm  
also not suggesting that this should happen all at once, causing  
upheaval and discord in the project, but rather constitute more of a  
"recommended direction" for future knob setting mechanisms.

To be more specific, rather than continue the proliferation of  
PortGroup foo and use_blah extensions, all of which basically cause  
"magic to happen" for the majority of Ports programmers rather than  
falling into some more coherent mental model for them, we could simply  
start fleshing out a class hierarchy for Ports and rolling the port- 
agnostic behavior into one or more classes, with a clearly defined  
mechanism for a Port to inherit from one or more classes or even other  
ports (that would certainly make the -devel ports a lot more  
concise).   I can think of several ways in which this could work, and  
an equal number of ways that this could look, but before I start  
tossing out Tcl procedure names and hypothetical Portfiles, I thought  
I'd first ask whether or not anyone even likes the idea or merely  
thinks I'm trying to turn a mountain of Tcl code into C++ (ye gods,  
no!).

Thoughts?

- Jordan

On Aug 22, 2009, at 1:03 PM, Ryan Schmidt wrote:

> On Aug 22, 2009, at 13:15, Jeremy Lavergne wrote:
>
>> On Aug 22, 2009, at 1:37 PM, Ryan Schmidt wrote:
>>
>>> Now that I think about it, the way these shortcuts are working now  
>>> is a little like portgroups. In fact all of it probably could be  
>>> implemented as a portgroup.
>>>
>>> PortGroup sourceforge 1.0
>>>
>>> PortGroup googlecode 1.0
>>>
>>> Might that simplify base code a bit?
>>
>> I'd suggest we do something akin to the extract options:  
>> use_sourceforge or use_googlecode.
>
> That would be another option.... But perhaps another motivation to  
> move the logic out of MacPorts base and into portgroups would be  
> that it can be updated without requiring a new release of MacPorts  
> base.