Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><code>new</code> builds the builder. You want some other method to actually return the built object.</p> <p>Here's an example:</p> <pre><code> class RepositoryBuilder { has 'allow_network_repositories' =&gt; ( is =&gt; 'ro', isa =&gt; 'Bool', required =&gt; 1, ); method build_repository(Uri $url) { confess 'network access is not allowed' if $url-&gt;is_network_url &amp;&amp; !$self-&gt;allow_network_repositories; my $class = $self-&gt;determine_class_for($url); # Repository::Whatever return $class-&gt;new( url =&gt; $url ); } } role Repository { &lt;whatever } class Repository::File with Repository {} class Repository::HTTP with Repository {} </code></pre> <p>Here, the builder and the built object are distinct. The builder is a real object, complete with parameters, that can be customized to build objects as the situation demands. Then, the "built" objects are merely return values of a method. This allows you to build other builders depending on the situation. (A problem with builder functions is that they are very inflexible -- it's hard to teach them a new special case. This problem still exists with a builder object, but at least your application can create a subclass, instantiate it, and pass this object to anything that needs to create objects. But dependency injection is a better approach in this case.)</p> <p>Also, there is no need for the repositories you build to inherit from anything, they just need a tag indicating that they are repositories. And that's what our <code>Repository</code> role does. (You will want to add the API code here, and any methods that should be reused. But be careful about forcing reuse -- are you sure everything tagged with the Repository role will want that code? If not, just put the code in another role and apply that one to the classes that require that functionality.)</p> <p>Here's how we use the builder we created. If, say, you don't want to touch the network:</p> <pre><code>my $b = RepositoryBuilder-&gt;new( allow_network_repositories =&gt; 0 ); $b-&gt;build_repository( 'http://google.com/' ); # error $b-&gt;build_repository( 'file:///home/whatever' ); # returns a Repository::Foo </code></pre> <p>But if you do:</p> <pre><code>my $b = RepositoryBuilder-&gt;new( allow_network_repositories =&gt; 1 ); $b-&gt;build_repository( 'http://google.com/' ); # Repository::HTTP </code></pre> <p>Now that you have a builder that builds the objects the way you like, you just need to use these objects in other code. So the last piece in the puzzle is referring to "any" type of Repository object in other code. That's simple, you use <code>does</code> instead of <code>isa</code>:</p> <pre><code>class SomethingThatHasARepository { has 'repository' =&gt; ( is =&gt; 'ro', does =&gt; 'Repository', required =&gt; 1, ); } </code></pre> <p>And you're done.</p>
    singulars
    1. This table or related slice is empty.
    1. POHow to have Moose return a child class instance instead of its own class, for polymorphism
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USjrockway
    1. USjrockway
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POHow to have Moose return a child class instance instead of its own class, for polymorphism
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COmmh... let me understand this role thing, back to the Moose docs... Also, my first thought about it, since i just begin with Moose, is whether it is still better to do bad Moose than not Moose
      singulars
      1. PO
      1. USAlex F
    2. CO@alex: if you follow the examples in Moose::Manual::*, you can use most of the features of Moose without running into difficulty. It's only when you start using `meta` that things get crazy :)
      singulars
      1. PO
      1. USEther
    3. COok, understood, but i am curious about the subtle differences: a) A Moose base class 'Repository' with all the base attributes; Specialized Moose classes 'Repository::_Sftp' that "extends"/inherits the base class; A moose(or not) factory 'RepositoryBuilder', with a method to create me an instance of the specialized class, that can be agnostically manipulated as a 'Repository'. b) The same as a), but with a role instead of the base class <- which is what you proposed, right ? c) and d) MooseX::AbstractFactory or MooseX::ABC , but these are not available by default (i take centos5 for ref)
      singulars
      1. PO
      1. USAlex F
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload