bless $x, undef to unbless #14684
Comments
From @epaCreated by @epaSometimes you need to unbless a scalar. Various CPAN modules exist to bless $x, undef; to unbless scalar $x. Note that this is not the same thing as bless $x; which should continue to bless into the current package. Perl Info |
From @kentfredricOn 1 May 2015 at 01:35, Ed Avis <perlbug-followup@perl.org> wrote:
Incidentally, Acme::Damn makes that syntax available: https://metacpan.org/pod/Acme::Damn#bless-reference-undef Unfortunately, its not presently an "error" if somebody does this without bless $x, undef Are both equivalent to bless $x, "main" perl -MData::Dump=pp -wE 'package Boss; my $x = bless {}, undef; Other than that, the proposal seems simple enough that I'm in favour of it. I just can't tell the scope of if any code is foolishly relying on this Obviously you can do damage prevention by making it a feature. -- *KENTNL* - https://metacpan.org/author/KENTNL |
|
The RT System itself - Status changed from 'new' to 'open' |
From @epabless $x, undef will currently generate two warnings, if warnings are enabled: Use of uninitialized value in bless For that reason I felt that changing the semantics would be reasonable. Oneliners may be written without warnings, but they rarely bless objects. For backwards compatibility I guess that bless $x, '' could continue to do what it does currently; only an explicit undef would cause the unblessing. -- This email is intended only for the person to whom it is addressed and may contain confidential information. Any retransmission, copying, disclosure or other use of, this information by persons other than the intended recipient is prohibited. If you received this email in error, please contact the sender and delete the material. This email is for information only and is not intended as an offer or solicitation for the purchase or sale of any financial instrument. Wadhwani Asset Management LLP is a Limited Liability Partnership registered in England (OC303168) with registered office at 40 Berkeley Square, 3rd Floor, London, W1J 5AL. It is authorised and regulated by the Financial Conduct Authority. |
From @avarOn Thu, Apr 30, 2015 at 3:51 PM, Ed Avis <eda@waniasset.com> wrote:
The main problem with this proposal is that now this code that warned bless $what{object}, $what{__PACKAGE__}; We could I guess generate a warning for trying to unbless an already bless {} => "main" for 1..2 ? I think this makes more sense as a new function Scalar::Util or something. Or maybe we could just ship Acme::Damn ?:) |
From @epaÆvar Arnfjörð Bjarmason <avarab <at> gmail.com> writes:
The cautious approach would be to make a hard deprecation cycle. I do think that C<bless $x, undef> is the logical way to express it and it -- |
From @leonerdOn Thu, 30 Apr 2015 16:26:43 +0200
As Scalar::Util's current maintainer, if anyone wants to throw me the use Scalar::Util 'unbless'; I'll happily merge it. -- leonerd@leonerd.org.uk |
From @epaunbless is already part of Data::Structure::Util (and other modules). -- |
From @avarOn Thu, Apr 30, 2015 at 4:30 PM, Ed Avis <eda@waniasset.com> wrote:
Aside from backwards compatibility concerns I don't like this API design. We have tie() and untie(), not untying as some special parameter to I know there's good reasons for why some of those couldn't get extra Also what should a function like this do? Objects are opaque and while unbless($obj); # or bless($obj, undef); .... Be: $obj = $obj->UNBLESS; # Or is that already ->FREEZE Which perhaps would fall back on a core method that would just remove You could argue that it should do exactly nothing except remove the |
From @kentfredricOn 1 May 2015 at 02:30, Ed Avis <eda@waniasset.com> wrote:
Another thought against: making undef remove bless instead of casting it A type of special casing that might put more burden on people using bless $x, $somename Due to the need to propagate the special case when $somename is not defined Imagine: sub foo { Given that currently, that would mean foo(undef, @args ); Would presently create a valid object, allbeit one they've got handling The new behaviour would create a non-object, which might croak/bail in That would be a step backwards. -- *KENTNL* - https://metacpan.org/author/KENTNL |
From @leonerdOn Thu, 30 Apr 2015 14:46:49 +0000 (UTC)
That's OK - perl's naming structure means that two different packages unbless is the sensible name for this function. Also it would be "surprising" to users if a "core"-style -- leonerd@leonerd.org.uk |
From @kentfredricOn 1 May 2015 at 02:48, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
A disadvantage of that approach is that it would be unsafe to use on my $ref = blessed $original ? $original->UNBLESS : $original # ew my $ref = UNIVERSAL::UNBLESS( $original ) ; # ew use Safe::Unbless; my $ref = $original->$_unbless; That would still be the case if we defined unbless not to work on already But seeing bless works on already blessed objects, it would break the -- *KENTNL* - https://metacpan.org/author/KENTNL |
From @epaÆvar Arnfjörð Bjarmason <avarab <at> gmail.com> writes:
If you introduce that, then the UNBLESS method would also have to be called Personally I would just like to set or unset the blessed field on the
I don't quite understand what you are getting at here. After all, an object package Foo; -- |
From @rjbs* Ævar Arnfjörð Bjarmason <avarab@gmail.com> [2015-04-30T10:48:39]
I agree with all of Ævar's objections.
I was really not sure about this, but the more I thought about it, the more I haven't given it a lot of thought (yet?). -- |
From @epaAn alternative proposal would be first to move Scalar::Util::blessed blessed($x) = 'Foo'; # blesses $x into package Foo But both this and C<bless $x, undef> work on a single scalar. One advantage of adding 'unbless' is that it can work on a list: unbless @a; # unblesses each element As it happens that is the use case I am thinking of - and it is in a hot So on reflection I think adding 'unbless' may be the best way. -- |
From @epaI wouldn't necessarily want to call a method every time I unbless an object. I don't buy the argument that adding raw_unbless will somehow violate the -- |
From @leonerdOn Thu, 30 Apr 2015 15:01:54 +0000 (UTC)
It doesn't need to be moved to be lvalue'able. It can have lvalue (I would prefer that it didn't though because Real Soon Now I'm going https://github.com/Scalar-List-Utils/Scalar-List-Utils/tree/pevans-custom-ops -- leonerd@leonerd.org.uk |
From @kentfredricOn 1 May 2015 at 03:07, Ed Avis <eda@waniasset.com> wrote:
I posit the frequency of using unbless is already low, and the desire for Conflating those 2 behaviours together just means if you want one without The last thing you want is do go "ok, I'm going to just unbless things so Similarly, using unbless on a list of objects seems infrequent enough that For instance, if unbless always took a list, then you're limiting your my $hash = unbless $ref, { destroy => 1 }; ^ would not be an option if: - unbless supported a list -- *KENTNL* - https://metacpan.org/author/KENTNL |
From @demerphqOn 30 April 2015 at 17:03, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
I am opposed to $obj->UNBLESS; Methods are overridable, and I would Also unblessing is a strange thing given that the *referent* not the Yves -- |
From @demerphqOn 30 April 2015 at 20:21, demerphq <demerphq@gmail.com> wrote:
I should have added, that DDS, which is Object::Deadly proof, achieves Yves -- |
From @ap* Ed Avis <perlbug-followup@perl.org> [2015-04-30 15:40]:
I’ve wished at various times that it existed, yes.
Opposed. There is absolutely no advantage to shoe-horning this into `bless`. * Ævar Arnfjörð Bjarmason <avarab@gmail.com> [2015-04-30 16:30]:
Aye. * Ævar Arnfjörð Bjarmason <avarab@gmail.com> [2015-04-30 16:50]:
Good point.
These issues are orthogonal. You are talking about the case in which encapsulation matters, i.e. But there is just as legitimately the case where I have an object from Both are valid use cases with different requirements, so arguing against * Ed Avis <eda@waniasset.com> [2015-04-30 17:10]:
Again with the shoe-horning. Why would you want to?
That is way low on the list of reasons to prefer a separate function, * Ed Avis <eda@waniasset.com> [2015-04-30 16:50]:
So having some random function called “unbless” in some random non-core … whereas having had `bless $thing, undef` as part of the language and I don’t understand this conception of “taken”. (And similarly with `blessed`, though much less strongly.) Mauve regards, |
From @epaC<bless $x, undef> produces two warnings if used. It is not documented in The consensus seems to have converged on adding 'unbless' for other reasons, If you think that C<bless $x, undef> is truly part of the language and -- |
From zefram@fysh.orgbless($x, undef) already has a defined meaning, and should not be changed. The appropriate way to invoke unblessing is as a subroutine supplied by This ticket should be closed. -zefram |
|
@cpansprout - Status changed from 'open' to 'rejected' |
From @epa
Could this be made a bit more explicit in perlfunc, not just for undef, but for blessing into the empty string too? I would use some wording like If CLASSNAME is omitted, the current package is used. An empty string (or undef) This is worth documenting since it's the one case where the string you get back I would also add a note To unbless a scalar, see the Data::Structure::Util module on CPAN. either in the perlfunc section above, or somewhere in perlfaq. |
From @epaP.S. perhaps the note 'make sure that CLASSNAME is a true value' should also be revisited, given that bless($x, undef) has a defined meaning and undef is not a true value. |
From zefram@fysh.orgDoc clarifications in commit b3893bf. -zefram |
From @epaThanks for making the documentation changes. |
Migrated from rt.perl.org#124428 (status was 'rejected')
Searchable as RT124428$
The text was updated successfully, but these errors were encountered: