Path: csiph.com!aioe.org!news.mb-net.net!open-news-network.org!.POSTED.100.225.197.178.dynamic.wless.zhbmb00p-cgnat.res.cust.swisscom.ch!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: comp.lang.javascript Subject: Re: Inserting stuff received with AJAX into the DOM Date: Sun, 27 Aug 2017 03:02:01 +0200 Organization: PointedEars Software (PES) Lines: 93 Message-ID: <2423280.mvXUDI8C0e@PointedEars.de> References: <7e54d58e-0ce6-4bb5-9f07-f65b69a94a64@googlegroups.com> <5846bd55-f0bd-4088-a596-aba50eef32a5@googlegroups.com> <11843581.uLZWGnKmhe@PointedEars.de> <7340100.T7Z3S40VBb@PointedEars.de> <19530051.EfDdHjke4D@PointedEars.de> <6718455.EvYhyI6sBW@PointedEars.de> <3126118.iIbC2pHGDl@PointedEars.de> <8133365.CDJkKcVGEf@PointedEars.de> Reply-To: Thomas 'PointedEars' Lahn Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit Injection-Info: gwaiyur.mb-net.net; posting-host="100.225.197.178.dynamic.wless.zhbmb00p-cgnat.res.cust.swisscom.ch:178.197.225.100"; logging-data="5429"; mail-complaints-to="abuse@open-news-network.org" User-Agent: KNode/4.14.2 X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. On 21/08/2017 22:16, Thomas 'PointedEars' Lahn wrote: >> Cezary Tomczyk wrote: >>> On 21/08/2017 17:47, Thomas 'PointedEars' Lahn wrote: >>>> Cezary Tomczyk wrote: >>>>> On 21/08/2017 16:44, Thomas 'PointedEars' Lahn wrote: >>>>>> Cezary Tomczyk wrote: >>>>>>> I am sure that: >>>>>>> >>>>>>> const par = document.createElement( 'p' ); >>>>>>> >>>>>>> will always create HTML element. I can't see any real scenario where >>>>>>> createElement method will return "something else than a reference to >>>>>>> an object that has a method named “appendChild”" in that particular >>>>>>> scenario. >>>>>> Why? >>>>> https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement >>>>> […] >>>> Certainly you can come up with something better than hearsay. >>> Possibly there is a better explanation than just hearsay. >> Possibly. Can you come up with it? > > No. I was expecting you'll do that. That is precisely your fallacy here. He who makes a claim carries the burden of proof to support it; not others carry the burden of proof to refute the same claim or prove the opposite claim. >> This is not about not feature-testing the createElement() method. It is >> about testing its return value before using that. > > Got it, but still I claim that in that particular case I would not test > it. It does not matter what you claim. It matters on what kind of reasoning you are basing your (design) decisions. >>> I might be wrong, but if there are cases that may strongly require "if" >>> here then I'd like to know. >> >> You are trying to shift the burden of proof again. You have claimed that >> this method can never return something unsuitable. So how do *you* >> support that claim *other* than with hearsay from MDN (I called it >> “hearsay” because it is a wiki and there is no other reference attached >> to your claim)? >> You have claimed that this method can never return something unsuitable. > > Let me clarify it: it may return something unexpected, but I've never > tested return value from createElement method before I use it because 1) > it was always working as expected and 2) I haven't got any scenario > where I could say it's required. That is precisely the problem. Your decisions are apparently based only on wishful thinking. >> So, what if no exception is being thrown by a method, would you not want >> to make sure as best as you can that the return value of a method is >> actually a reference to an object, before you attempt to access its >> properties? > > Generally yes, but as for the returns from createElement method I do not > do that. Not being based on sound reasoning, your decision-making process is not logical. >>> and unless it's not modified it has been always working quite good. >> Based on what *data*? > > Own experience. Do you realize that one’s experience is limited? > I'd rather strongly urge to give me a scenarios where createElement > method returns something different than created HTML element. I'd like > to understand why do I need to test a return value of createElement > method if it's actually a reference to an object, before I attempt to > access to it's properties. You are trying to shift the burden of proof again. I am not playing that game. Also, please trim your quotes from now on. . . . -- PointedEars FAQ: | | Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.