On Sunday, 11 March 2012 at 00:43:15 UTC, H. S. Teoh wrote:
> The problem is not what JS solves, per se, but the fact that many web developers use it for no good reason at all besides
> the fact that it's the "cool new thing".

hey did you guys hear that you can convert a lot of
D code to Javascript?

It's cool. It's new. And it's a thing.

Use it!

On 03/10/2012 02:06 AM, Andrei Alexandrescu wrote:
> On 3/9/12 5:05 PM, Adam D. Ruppe wrote:
>> On Friday, 9 March 2012 at 23:50:50 UTC, bearophile wrote:
>>> At first I didn't like it a lot because it's cheap syntax sugar that
>>> adds no new power and gives programmers more freedom to write
>>> different-looking versions of the the same code (and this is often bad).
>>
>> What I like about is the encapsulation benefits. You
>> don't have to know if the function is a method or an
>> external function, it just works.
>>
>> External, non-friend (so separate module in D) functions
>> are often preferable to methods because they don't have
>> access to the class' private members, so they cannot rely
>> on those implementation details.
>>
>> Extending objects with new functions in this way also
>> means you don't break binary compatibility with the
>> existing code, since it isn't modified at all!
>>
>>
>> Of course, you could always do this with the old
>> syntax too, but then the syntax preference means
>> you are biased toward one implementation or the
>> other - it doesn't mesh as well and you may be
>> tempted to make things methods for the syntax,
>> despite the cost in compatibility.
>>
>> UFCS rox.
>
> Insert obligatory link: http://drdobbs.com/184401197
>
> Very insightful article.
>
>
> Andrei

How can:

class Wombat {
  void nap() {
    this->sleep();
  }
}

increase encapsulation? It's using public API, so client code can't break if you keep the sleep method there.

Now, I do agree that it's nice to not have additional methods defined because it speeds up parsing and doesn't bloat the interface. I just don't agree with implementing it as UFCS.

Take a look a this:

void nap(Wombat wombat) { }
void somethingElse(Wombat wombat, int x) { }
void anotherThing(Wombat wombat, int x) { }

Compared to this:

class Wombat {
  void nap() {}
  void somethingElse(int x);
  void anotherThing(int x);
}

Shorter, grouped, cleaner (in my opinion). No repetition of Wombat all over the place.

In fact, it should be much easier to implement. When extending a class, associate those methods to the class, then do a normal lookup. With UFCS you'd have to look for a global function whose first parameter is the Wombat. So you have two searches: first find members, then public functions (I wonder why UFCS is not completely implemented so far).

Explaining an extension method is also easy: "If you extend a class's methods, those can only access public member functions". Now you'd have to say "Any global function that has this class as a first parameter can be invoked as a member function, removing this first parameter".

Well... I'm just looking for consistency.

This is exactly what happens in Ruby:

irb(main):001:0> Time.parse "2012-01-02"
NoMethodError: undefined method `parse' for Time:Class
	from (irb):1
	from :0
irb(main):002:0> require 'time'
=> true
irb(main):003:0> Time.parse "2012-01-02"
=> Mon Jan 02 00:00:00 -0300 2012

Well, in Ruby you can access private members in those extensions... I don't want that in D. So I guess one complaint for what I'm saying is "Oh, people will think that you can access private members in those extensions because they have the same syntax blah blah blah".

On 03/10/2012 10:03 PM, Ary Manzana wrote:
> On 03/10/2012 02:06 AM, Andrei Alexandrescu wrote:
>> On 3/9/12 5:05 PM, Adam D. Ruppe wrote:
>>> On Friday, 9 March 2012 at 23:50:50 UTC, bearophile wrote:
>>>> At first I didn't like it a lot because it's cheap syntax sugar that
>>>> adds no new power and gives programmers more freedom to write
>>>> different-looking versions of the the same code (and this is often
>>>> bad).
>>>
>>> What I like about is the encapsulation benefits. You
>>> don't have to know if the function is a method or an
>>> external function, it just works.
>>>
>>> External, non-friend (so separate module in D) functions
>>> are often preferable to methods because they don't have
>>> access to the class' private members, so they cannot rely
>>> on those implementation details.
>>>
>>> Extending objects with new functions in this way also
>>> means you don't break binary compatibility with the
>>> existing code, since it isn't modified at all!
>>>
>>>
>>> Of course, you could always do this with the old
>>> syntax too, but then the syntax preference means
>>> you are biased toward one implementation or the
>>> other - it doesn't mesh as well and you may be
>>> tempted to make things methods for the syntax,
>>> despite the cost in compatibility.
>>>
>>> UFCS rox.
>>
>> Insert obligatory link: http://drdobbs.com/184401197
>>
>> Very insightful article.
>>
>>
>> Andrei
>
> How can:
>
> class Wombat {
> void nap() {
> this->sleep();
> }
> }
>
> increase encapsulation? It's using public API, so client code can't
> break if you keep the sleep method there.
>
> Now, I do agree that it's nice to not have additional methods defined
> because it speeds up parsing and doesn't bloat the interface. I just
> don't agree with implementing it as UFCS.
>
> Take a look a this:
>
> void nap(Wombat wombat) { }
> void somethingElse(Wombat wombat, int x) { }
> void anotherThing(Wombat wombat, int x) { }
>
> Compared to this:
>
> class Wombat {
> void nap() {}
> void somethingElse(int x);
> void anotherThing(int x);
> }
>
> Shorter, grouped, cleaner (in my opinion). No repetition of Wombat all
> over the place.
>
> In fact, it should be much easier to implement. When extending a class,
> associate those methods to the class, then do a normal lookup. With UFCS
> you'd have to look for a global function whose first parameter is the
> Wombat. So you have two searches: first find members, then public
> functions (I wonder why UFCS is not completely implemented so far).

I forgot to say: if you implement it by associating it to the type, you can also use the current method lookup algorithm because it will search in super classes. With UFCS you'd have to search for public functions whose first parameter are B, then public functions whose first parameter are A, etc, assuming A extends B.

So not only it's easier to write and read, but also easier to implement.

"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.447.1331426602.4860.digitalmars-d@puremagic.com...
> On Sat, Mar 10, 2012 at 05:45:33PM -0500, Nick Sabalausky wrote:
>> "Everyone" *isn't* using it (even for a non-literal usage of "everyone").  And I have it turned off because the web is not *not only* "unpleasant" with it *on*, but, for me, borderline unusable.
>
> I used to do that. :-)
>
> These days, I just can't be bothered what someone does or doesn't do with JS on their site.  Opera lets me configure scripting on a per-site basis. As soon as I run into a site that uses annoying scripting, it's bye-bye scripting for that site forever.
>

I use the NoScript addon for FireFox, which does the same thing. But I have my default set to "off" because I find that's usually the prefereable option. Even on sites that break without JS, viewing them with JS on is usually not much better - at least with JS off, they break *quickly* without wasting my time spinning their AJAX and jQuery wheels just so they can *sort of* work very, very slowly.

> In the past, I've even used UserJS to *edit* the site's JS on the fly to rewrite stupid JS code (like replace sniffBrowser() with a function that returns true, bwahahaha) while leaving the rest of the site functional. I do not merely hate Javascript, I fight it, kill it, and twist it to my own sinister ends.  >:-)
>

I admire that :) Personally, I don't have the patience. I just bitch and moan :)

>
> [...]
>> > I would think that you'd be running into problems like that all the time with the esoteric web browsing setup that you have.
>
> Esoteric?! Really? Whatever happened to those days of graceful degradation?
>

Why would you want graceful degredation? That would defeat the whole point: The whole point of our crusade is to *force* what we *know* to be newer and better unto all the unwashed masses.

Along the same lines: How long do you think it'll be before a cellular connection starts being required for using the internet? Or just certain sites?

Some people may think that's silly, but it's already happened for IM: Remember when IM was free ans accessible through *any* internet connection? Why was anyone ever willing to use that? Didn't they know get could *pay* to get the exact same service thanks to SMS? The IM networks still techincally exist, but you can't use them because everyone you'd talk to prefers to pay a cell company for SMS. Why use something free and open when you can pay for restricted access?

> Or are we sliding back into the bad ole days of gratuitous incompatibilities?

When has the web *ever* had that?  (Well, in 1996 maybe.)

But yea, I often feel like we've moved back into the old DOS days when software packages didn't interoperate, and data was almost inseperable from its software.

In 1994, games had to come with their own sound/video drivers. In 1995, MS fixed that and there was much rejoicing.

But in 2012:

- Every piece of content is packaged with a pre-chosen viewer.

- Every web site feels it has to include it's own social networking links.

- If you want to use GitHub/BitBucket-style DVCS features you have to use whichever interface is *provided* by whoever's hosting the repo. BitBucket can't access GitHub-hosted repos/projects. GitHub can't acces BitBucket-histed repos/projects. Neither can access local or self-hosted repos/projects. WTF is this, 1990 all over again?

And any mention of "maybe these aren't the best ways" is met with cries of "Heresy! Conform, you dinosaur!".

> And here I was, thinking that the W3C was attempting
> to make things interoperate...

Hah! I think the only thing the W3C is attempting to do is see how long they can do nothing before people start to call them on it.

Well, that's not fair. It's probably not "nothing". I'm sure there's also a bunch of "Google trying to throw their weight around" and "Everyone, ignore all the suggestions from MS - they're wrong by default, especially their box model, JS mouse-button API, and other such things that make our standards appear to be designed by retarded monkeys - it's just their way to trick us!".

>
>> It may seem that way, but it's *much* less trouble then what I had before I blocked flash (with NoScript), installed AdBlock Plus, and disabled JS (also with NoScript). Seriously. No exaggeration. I literally *cannot* read a page when there's shit animating around it.
> [...]
>
> Opera has content blocking. :-) It's configurable per-site, even. I actively use it on sites where things flash around for no good reason.

Yup, same with NoScript. It replaces Flash and Java applets with placeholder boxes. In the rare cases where I want to view it, I just click it. Per-site configurable, too.

> OTOH, when >50% of a site is just random animated junk, I just leave and never return, 'cos whoever runs the site obviously doesn't have anything useful to offer me anyway. It's a pretty reliable indicator of site quality, actually. And of whether I want to bother giving it another second of my time.
>

Yea.

>
> -- 
> "640K ought to be enough" -- Bill G., 1984. "The Internet is not a primary goal for PC usage" -- Bill G., 1995. "Linux has no impact on Microsoft's strategy" -- Bill G., 1999.

I've heard that Gates never actually said that "640k" quote. (Don't know whether that's true or not, though :/ )

"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:uzpluzrtlvsspppwwakl@forum.dlang.org...
> On Sunday, 11 March 2012 at 00:43:15 UTC, H. S. Teoh wrote:
>> The problem is not what JS solves, per se, but the fact that many web
>> developers use it for no good reason at all besides
>> the fact that it's the "cool new thing".
>
> hey did you guys hear that you can convert a lot of
> D code to Javascript?
>
> It's cool. It's new. And it's a thing.
>
> Use it!

It's a thing? I gotta have it!

:)

"Andrej Mitrovic" <andrej.mitrovich@gmail.com> wrote in message news:mailman.441.1331421065.4860.digitalmars-d@puremagic.com...
> On 3/10/12, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
>> I've always believed that Javascript is the hellspawn of evil incarnate.
>
> You and Nick just became best friends! :P

No no, he's speaking heresy. Javascript *is* evil incarnate. It's also evil carnitas and semi-evil carnies. What whacko would think it's the hellspawn *of* evil incarnate? That's just silly!

"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.436.1331412193.4860.digitalmars-d@puremagic.com...
> On Sat, Mar 10, 2012 at 02:56:00PM -0500, Nick Sabalausky wrote:
>> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.412.1331398464.4860.digitalmars-d@puremagic.com...
>> >
>> > Breaking changes tend to happen inside a class, so if something doesn't *need* access to private members, then it doesn't, and shouldn't, need to be a class member.
>> >
>>
>> Unless they need polymorphism :(
>
> True.
>
> Every now and then I still mull over how to reconcile class hierarchies with generic programming. I mean, inheritance and polymorphism are definitely very powerful concepts, but once you throw templates into the mix, the two don't quite get along very well (they try to, but every now and then they get into a fight). I mean, conceptually speaking, templated members should be polymorphic too, but then it's impossible to implement in code.
>
> Really makes me wonder if there's something out there, some brand new unifying concept, that can marry the two and retain their best characteristics. Or perhaps a revolutionary new concept that replaces inheritance and templates with something even more powerful.
>

My understanding is that the *only* thing preventing vitrual template functions is the possibility of pre-compiled closed-source static libs. Which is why I've long been in favor of allowing vitrual template functions *as long as* there's no closed-source static libs preventing it. Why should OSS have to pay costs that only apply to closed source?

>>
>> It also has the benefit of shrinking the vtables of each instance. (Although I think 'final' might have the same effect if used the same way?)
>
> I don't know about that, what if it's a final override? (Or is that
> illegal in D?)
>

That's what I was alluding to with "if used the same way". Ie, if it's statically know to not override or be overridden (I guess I wasn't clear). I'm pretty sure D allows final override, and yea, naturally that would require a vtable entry. But if it's a non-override final, a vtable entry isn't necessary.

Now, as for whether or not D actually *does* omit the vtable entry for non-override finals, I wouldn't know. Although I seem to vaguely remember doing optimizations once that seemed to imply it did. If that's so, I don't know whether its guaranteed per D spec or just implementation-defined. A UFCS approach would definitely be guaranteed not to affect the vtable, of course.


>> > There are two ways to write error-free programs; only the third one works.
>>
>> Heh, once again, a gem. I also laughed out loud at the "That phone number is imaginary, rotate your phone 90 degrees and try again".
> [...]
>
> One of the ones that made me LOL when I first heard it was:
>
> I am Ohm of Borg. Resistance is voltage over current.
>
> :-)
>

Heh :)

>
> -- 
> Famous last words: I wonder what will happen if I do *this*...

Another great one, which is very similar to one I've enjoyed repeating:

What are a redneck's last words? "Hey y'all, watch this!"

Not sure where that's from, but Jeff Foxworthy would probably be a safe guess.

"Nick Sabalausky" <a@a.a> wrote in message news:jjh9uh$1vto$1@digitalmars.com...
>
> My understanding is that the *only* thing preventing vitrual template functions is the possibility of pre-compiled closed-source static libs. Which is why I've long been in favor of allowing vitrual template functions *as long as* there's no closed-source static libs preventing it. Why should OSS have to pay costs that only apply to closed source?
>

That's not really it...

The problem is that vtables contain every virtual function of a class - and if you instantiate a template function with a new type, it would require a new vtable entry.  Therefore you need to know how every template function in every derived class is instantiated before you can build the base class vtable.  This doesn't work with D's compilation model.

>
> Now, as for whether or not D actually *does* omit the vtable entry for non-override finals, I wouldn't know. Although I seem to vaguely remember doing optimizations once that seemed to imply it did. If that's so, I don't know whether its guaranteed per D spec or just implementation-defined. A UFCS approach would definitely be guaranteed not to affect the vtable, of course.
>

D (dmd) does not create a vtable entry for final functions that don't override anything.  It's in the frontend, so it should be the same for all the d compilers.

On Sat, Mar 10, 2012 at 11:31:47PM -0500, Nick Sabalausky wrote:
> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.436.1331412193.4860.digitalmars-d@puremagic.com...
[...]
> My understanding is that the *only* thing preventing vitrual template functions is the possibility of pre-compiled closed-source static libs.  Which is why I've long been in favor of allowing vitrual template functions *as long as* there's no closed-source static libs preventing it. Why should OSS have to pay costs that only apply to closed source?

I thought the reason was that every instance of the template will need a vtable entry, and the compiler may not be able to know beforehand which instances will actually exist? You *could* in theory have the compiler scan the entire program for all instances, I suppose, but that will prevent incremental compilation and loading of dynamic libs, OSS or not. Plus it may slow down the compiler significantly.


[...]
> Another great one, which is very similar to one I've enjoyed repeating:
> 
> What are a redneck's last words? "Hey y'all, watch this!"
[...]

And another one in response:

	Famous last words: I *think* this will work...


T

-- 
It won't be covered in the book. The source code has to be useful for something, after all. -- Larry Wall

On Sat, Mar 10, 2012 at 09:14:26PM -0500, Nick Sabalausky wrote:
> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.447.1331426602.4860.digitalmars-d@puremagic.com...
[...]
> > In the past, I've even used UserJS to *edit* the site's JS on the fly to rewrite stupid JS code (like replace sniffBrowser() with a function that returns true, bwahahaha) while leaving the rest of the site functional.  I do not merely hate Javascript, I fight it, kill it, and twist it to my own sinister ends.  >:-)
> >
> 
> I admire that :) Personally, I don't have the patience. I just bitch
> and moan :)

Well, that was in the past. Nowadays they've smartened up (or is it dumbened down?) with the advent of JS obfuscators. Which, OT1H, is silly because anything that the client end can run will eventually be cracked, so it actually doesn't offer *real* protection in the first place, and OTOH annoying 'cos I really can't be bothered to waste the time and effort to crack some encrypted code coming from some shady site that already smells of lousy design and poor implementation anyway.

So I just leave and never come back to the site.


[...]
> In 1994, games had to come with their own sound/video drivers. In 1995, MS fixed that and there was much rejoicing.
> 
> But in 2012:
> 
> - Every piece of content is packaged with a pre-chosen viewer.

Blame flash. And JS.


[...]
> - If you want to use GitHub/BitBucket-style DVCS features you have to use whichever interface is *provided* by whoever's hosting the repo. BitBucket can't access GitHub-hosted repos/projects. GitHub can't acces BitBucket-histed repos/projects. Neither can access local or self-hosted repos/projects. WTF is this, 1990 all over again?

Yeah seriously. So much for "semantic web". Smells like a pipe dream to me.


[...]
> > "640K ought to be enough" -- Bill G., 1984. "The Internet is not a primary goal for PC usage" -- Bill G., 1995. "Linux has no impact on Microsoft's strategy" -- Bill G., 1999.
> 
> I've heard that Gates never actually said that "640k" quote. (Don't know whether that's true or not, though :/ )
[...]

Ahh, the stuff that urban legends are made of...


T

-- 
The two rules of success: 1. Don't tell everything you know. -- YHL