So, I would *love* to see proper inheritance for Types.

Currently, I can inherit Providers and do classic OO stuff but I can't do
that with Types and it drives me a bit nuts.

If you go with the descriptive namevar, you'll need to make the separator
something that won't show up in a package name. So probably one of '+/,|'
etc...

The bright side of this is that you don't need to specify the provider
either since it can be auto-determined from the namevar.

package { 'mysql+gem': ensure => 'foo' } ==> Name is known to be mysql and
provider is known to be gem from splitting on '+'.

You can find an example of this here:
https://github.com/onyxpoint/pupmod-concat/blob/master/lib/puppet/type/concat_fragment.rb

But, I still would prefer just inheriting types.

Puppet::Type.newtype(:package_gem, :parent => Puppet::Type::Package)

This would mean that I would obtain all methods, properties, and parameters
from the parent Type and be able to override/extend as usual.

Providers would not be inherited, only the Type API.

Trevor

On Wed, Oct 8, 2014 at 7:55 AM, Felix Frank <felix.fr...@alumni.tu-berlin.de
> wrote:

> On 10/08/2014 01:23 PM, Trevor Vaughan wrote:
> >
> > service { 'my_service': require => Package['mysql']{ :provider => 'gem'
> } }
>
> How about require => Package<| title == 'mysql' and provider == 'gem' |>
>
> Not that it matters - having two Package[mysql] resources will *never*
> be a thing.
>
> If I understand Andy correctly, we might have something like
>
> package { 'mysql-gem': package_name => mysql, provider => gem }
>
> ...which is awful I guess. Anyway, relationship targets will not be
> jeopardized (that I can see).
>
> > Types of Users: <the usual>, htaccess, htdigest, tomcat, ldap(posix),
> > ldap(other), weblogic, mysql, postgres, dovecot, postfix, (pretty much
> > you name it....)
> >
> > Personally, I don't want all of these smashed into the same high level
> > interface.
>
> Hmm, I think I agree (right now...let's see about next week ;-)
>
> But we *do* need a subtyping system then. You wouldn't want to implement
> each of those as their own independent thing, would you?
>
> Cheers,
> Felix
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/54352621.7050200%40alumni.tu-berlin.de
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXF8fCC_b6ZMQsyiOdnWm47fzQJOL7c%3D2vy6ri5Cia_bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to