From Newsgroup: comp.lang.javascript

On Thu, 22 Feb 2024 11:37:52 +0100, Mild Shock wrote:

But I have my doubts.

Show us your non-method-chained-style version, then.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

No syntactical doubts, only semantical doubts:

So method chaining might not always satisfied the
same expectations about being a more "functional" approach.

Guido von Rossum suggest to not always use method chaining:

https://mail.python.org/pipermail/python-dev/2003-October/038855.html

Lawrence D'Oliveiro schrieb:

On Thu, 22 Feb 2024 11:37:52 +0100, Mild Shock wrote:

But I have my doubts.

Show us your non-method-chained-style version, then.

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

On Fri, 23 Feb 2024 00:49:08 +0100, Mild Shock wrote:

Lawrence D'Oliveiro schrieb:

On Thu, 22 Feb 2024 11:37:52 +0100, Mild Shock wrote:

But I have my doubts.

Show us your non-method-chained-style version, then.

Guido von Rossum suggest to not always use method chaining:

Which is not really answering my question, is it?
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.lang.javascript

On 23/02/2024 01:40, Lawrence D'Oliveiro wrote:

On Fri, 23 Feb 2024 00:49:08 +0100, Mild Shock wrote:

Lawrence D'Oliveiro schrieb:

On Thu, 22 Feb 2024 11:37:52 +0100, Mild Shock wrote:

<snip>

Guido von Rossum suggest to not always use method chaining:

Which is not really answering my question, is it?

In some scenarios it makes sense to allow chaining.
For instance when building the answer to a query where the parts to be included depend on circumstances. As in x.a().b().e().g();

In other scenarios it just makes things confusing for anyone reading the
code, including the writer.

In other words it depends on design judgement, something that disturbs
people who prefer a 300 page book of rules.

John

--- Synchronet 3.21b-Linux NewsLink 1.2