php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #54698 setAttribute
Submitted: 2011-05-10 00:15 UTC Modified: 2011-05-10 10:52 UTC
From: broshizzledizzle at gmail dot com Assigned:
Status: Wont fix Package: DOM XML related
PHP Version: Irrelevant OS: (irrelevant)
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: broshizzledizzle at gmail dot com
New email:
PHP Version: OS:

 

 [2011-05-10 00:15 UTC] broshizzledizzle at gmail dot com 
Description:
------------
It makes more sense for setAttribute() to return the object it was called on 
instead of the attribute that was set.  If I was interested in the attribute, I'd 
have use createAttribute() instead.

Test script:
---------------
$dom = new DOMDocument();
$body = $dom->createElement('body');
$dom->appendChild($body->setAttribute('class', 'wrapper'));
echo $dom->saveHTML();

Expected result:
----------------
I would expect that it would properly append $body to the $dom.

Actual result:
--------------
Warning: DOMNode::appendChild() [domnode.appendchild]: Couldn't append node in 
_FILE_ on _LINE_.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-05-10 10:17 UTC] aharvey@php.net
-Status: Open +Status: Wont fix
 [2011-05-10 10:17 UTC] aharvey@php.net 
Given how widely the DOM extension is used, I don't think it would be
a good idea to break backward compatibility now, even in a good cause.

Closing won't fix.
 [2011-05-10 10:35 UTC] broshizzledizzle at gmail dot com 
I understood the implication of what I suggested when I posted.  This exact same 
flaw happens in so many methods of the DOM that I always have to look up return 
values to see what actually gets returned, rather than what would be useful.

I'm not looking to get into a fight, but think about what you said: "I don't 
think it would be
a good idea to break backward compatibility now, even in a good cause."  Doesn't 
that grate on your nerves?  You are saying, we won't right the wrong we made in 
the beginning because a lot of people use this extension.  Ever heard of 
investing in your future? I don't think PHP is going to die anytime soon, and if 
we're going to ever improve the DOM in this regard we'll probably never have a 
better time.  It'll just get harder the longer we wait.
 [2011-05-10 10:52 UTC] rasmus@php.net 
I think if we were to fix it, we would make it return void or false on an error 
to comply better with the DOM spec. Changing it from one value that doesn't 
comply with the spec to another one that also doesn't comply doesn't make much 
sense.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 13:01:31 2024 UTC