hai mark
i thought about,
and what about hybrid API,
so you can do it positional and if there is only one param hasref i do it the
current way. would be that acceptable for an Wx::Perl::* module?
best
herbert
btw I'm registering the Namespace Bundle::Wx::Perl right now
Am 01.09.2012 13:42, schrieb Mark Dootson:
> Hi,
>
> On 31/08/2012 20:49, herbert breunung wrote:
>> Allright,
>>
>> I alright wrote here that I do currently some helper modules and after im
>> more
>> familiar with dzil and their API gets more stable i want to ship them to
>> cpan.
>> However after we get more and more Wx::Perl modules (didnt knew even
>> Wx::Perl::ListCtrl) i would like du bundle them into the module Wx::Perl
>> or Wx::Perl::Bundle.
>
> I think the Wx::Perl:: namespace has always indicated pure Perl modules so
> "Wx::Perl::Bundle" looks like a good name for a bundle of all of these.
>
>>
>> However the more important question I like to ask you all is how consistent
>> has the API be bewtween all of these modules. Especially what is now
>> Kephra::App::Splitter has named parameters because IMO
>>
>> ....Splitter->new( parent => $win, $left=> $w1, right=> $w2, gravity=>
>> 'left');
>>
>> is to me much clearer.
>>
>> im really interested i you view.
>
> I think the modules on CPAN generally stick to the parameter conventions of
> the existing main Wx.
>
> I think that probably many long time Wx users have their own versions of this
> in place. Having to pass all previous parameters when you just want a 'style'
> generally drives a person to implement a way of overcoming this.
>
> The GUI parts of Citrus Perl rely on a set of modules prefixed CP::Wx:: that
> take care of this. The modules themselves are just a renamed port of internal
> modules in other applications.
>
> For example, a code snippet
>
> ----------------------------
>
> my $dname_label = CP::Wx::StaticText->new($self, label => t('Distribution'));
> my $dname = CP::Wx::ValidatedText->new($self, vdata => $vdata, vdatafield
> => 'citrusname', style => wxTE_READONLY);
> my $version_label = CP::Wx::StaticText->new($self, label => t('Version'));
> my $version = CP::Wx::ValidatedText->new($self, vdata => $vdata,
> vdatafield => 'citrusversion', style => wxTE_READONLY);
> my $perl_label = CP::Wx::StaticText->new($self, label => t('Perl'));
> my $perl = CP::Wx::ValidatedText->new($self, vdata => $vdata, vdatafield
> => 'citrusperl', style => wxTE_READONLY);
> my $widgets_label = CP::Wx::StaticText->new($self, label =>
> t('wxWidgets'));
> my $widgets = CP::Wx::ValidatedText->new($self, vdata => $vdata,
> vdatafield => 'citruswidgets', style => wxTE_READONLY);
>
> -----------------------------
>
> Examples of simple wrappers are in CP::Wx::Control and the code that makes it
> work is in CP::Wx::Window. It is intended to make it v simple to implement new
> wrappers for new controls simply by looking at CP::Wx::Control.
>
> It currently lurks only in Citrus Perl as probably CP::Wx:: is not a
> reasonable namespace - but I like it being short. Also, such things are fairly
> useless to a wider community without documentation.
>
> So - in answer to your question - yes, named params make absolute sense to me
> - but my view is that it needs to be outside the main Wx dist. The main Wx
> dist replicates as far as is possible the C++ interface - which means that the
> C++ docs, more or less, work for wxPerl too.
>
>
> I hope the above relates to your questions.
>
> Regards
>
> Mark
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>>
>> best
>> herbert aka lk
>
>
