On 11/03/2012 19:44, Nick Sabalausky wrote:
<snip>
> I wouldn't make it an online editor.  Just let a normal editor
> access remote files.  Done.  As for specifically html documents on
> the web, doesn't http already have provisions for updating anyway?

HTTP has a PUT method, but I'm not sure it's widely supported.  Nowadays, practically everyone uses FTP to upload web pages.  Either that or a web-based file manager such as free hosts tend to provide instead of FTP access.

> Hell, the *original* web browser was *both* an editor and a viewer.

What kind of editor - raw HTML, WYSIWYM, WYSINWYG or something else entirely?

> But then Mosaic came along, scrapped the editor part, and
> everything since has followed suit.

I guess the authors of Mosaic were bothered about enabling people to browse the web, rather than to create web pages.

But there were a few other combined browsers and editors to come, like Netscape Navigator Gold (the editor part of which later broke away into Netscape Composer, or so I was told)....

Stewart.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:jjj6lo$2ojb$1@digitalmars.com...
> On 11/03/2012 19:44, Nick Sabalausky wrote:
> <snip>
>> I wouldn't make it an online editor.  Just let a normal editor access remote files.  Done.  As for specifically html documents on the web, doesn't http already have provisions for updating anyway?
>
> HTTP has a PUT method, but I'm not sure it's widely supported.  Nowadays, practically everyone uses FTP to upload web pages.  Either that or a web-based file manager such as free hosts tend to provide instead of FTP access.
>

Yea, but it doesn't have to be that way. Browsers have moved away from HTTP for such things and don't even support it, so most people don't even know that it's always been (supposed to be) possible.

>> Hell, the *original* web browser was *both* an editor and a viewer.
>
> What kind of editor - raw HTML, WYSIWYM, WYSINWYG or something else entirely?
>

I'm not sure. Probably raw HTML I would guess, but obviously it could have been implemented to do it in any mannar. You can probably look it up on Wikipedia. IIRC, it was actually *named* either "WWW" or "World Wide Web".

>> But then Mosaic came along, scrapped the editor part, and everything since has followed suit.
>
> I guess the authors of Mosaic were bothered about enabling people to browse the web, rather than to create web pages.
>
> But there were a few other combined browsers and editors to come, like Netscape Navigator Gold (the editor part of which later broke away into Netscape Composer, or so I was told)....
>

Interesting, I'd never even heard of that. I think I've heard the name "Netscape Composer" but just assumed it was an email client.

On 11/03/2012 22:36, Nick Sabalausky wrote:
<snip>
>>> Hell, the *original* web browser was *both* an editor and a viewer.
>>
>> What kind of editor - raw HTML, WYSIWYM, WYSINWYG or something else
>> entirely?
>
> I'm not sure. Probably raw HTML I would guess, but obviously it could have
> been implemented to do it in any mannar. You can probably look it up on
> Wikipedia. IIRC, it was actually *named* either "WWW" or "World Wide Web".
<snip>

It was WorldWideWeb actually.  Later renamed to Nexus as the original name was deemed confusing.

Stewart.

On 2012-03-11 20:55, Nick Sabalausky wrote:
> Mobile sites have traditionally required less-fancy implementations, so it's
> not unreasonable to think that some sites would use their mobile version
> *as* their low-tech fallback version. That's becoming less and less true
> these days, of course. But looking at http://m.drdobbs.com/ I have a strong
> feeling that was originally created for things like AvantGo (ie, on PalmOS)
> which really were very limited: no JS, no nested tables, very low
> resolution, often not even any color, very low memory, etc. Not that
> anything about what they're doing really makes a whole lot of sense anyway,
> though.

Actually, on some sites I use the mobile version, on the desktop. Just because it's so much more clean and not as verbose.

-- 
/Jacob Carlborg

On Sat, 10 Mar 2012 14:41:53 -0500, Nick Sabalausky <a@a.a> wrote:

> You know what I think it is (without actually looking at the code): I think
> they tried to do some highly misguided and even more poorly implemented hack
> (which they no-doubt thought was clever) for dealing with *cough* "old"
> *cough* browsers by inserting a meta redirect to a hardcoded URL, and then
> used JS to disable the meta redirect. If that's the case, I don't know how
> the fuck they managed to convince themselves that make one drop of sense.

It could be that they don't care to cater to people who hate JS.  There aren't that many of you.

You may want to consider -- if you on principle don't view pages with information because the pages contain JS, you are the one missing out on the information.

If you worked for my company, and you didn't like JS, you'd have a tough (actually impossible) time using the web application we have for tracking things.

-Steve

On Sat, 10 Mar 2012 00:06:40 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Insert obligatory link: http://drdobbs.com/184401197
>
> Very insightful article.

Interesting point to make about D, however.  It's really *difficult* to make related non-member non-friend functions, since all functions inside the same module as a type are friends.  In order to follow the recommendations, D non-member non-friend functions must go in another *module*.

I don't necessarily agree with the argument, because it's a fully-objective view of something that is very subjective.

For instance:

class A
{
   private int a;
}

class B
{
   private int b;
}

void nonMemberBFunction(B b)
{
   b.b = 5;
}

Not only is nonMemberBFunction potentially dependent on B's implementation, but it's also potentially dependent (by Scott's rules) on A's implementation.  Therefore, A has less encapsulation.

But any sane person can see that nonMemberBFunction does not access A.  Since everything to be examined/updated when updating A's implementation is in the same file (and that implementation is readily available), I think you should not count non-member functions that don't *access* the class in question against the encapsulation factor.  Yes, this makes things more reliant on convention (i.e. denote in documentation somehow what functions access private data), but since you can't turn friends off without extreme practices, I don't think you have any other sane choices.

In D, interestingly, making things member functions is not any different than making them non-members, it seems.  In fact, I'd argue it's *more* appropriate in D to make things member functions, since it serves as implicit documentation that it likely accesses only the class members.  I wonder what Scott would say about that?

-Steve

On Sun, 11 Mar 2012 00:18:31 -0500, Daniel Murphy <yebblies@nospamgmail.com> wrote:

> "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.

You could do it if the vtable was a hash instead of an array (or at least the template portion was).  But that's just asking for horrible performance, and I don't think it's worth it.

But I think it is possible...

-Steve

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:op.wa1432xjeav7ka@localhost.localdomain...
> On Sat, 10 Mar 2012 14:41:53 -0500, Nick Sabalausky <a@a.a> wrote:
>
>> You know what I think it is (without actually looking at the code): I
>> think
>> they tried to do some highly misguided and even more poorly implemented
>> hack
>> (which they no-doubt thought was clever) for dealing with *cough* "old"
>> *cough* browsers by inserting a meta redirect to a hardcoded URL, and
>> then
>> used JS to disable the meta redirect. If that's the case, I don't know
>> how
>> the fuck they managed to convince themselves that make one drop of sense.
>
> It could be that they don't care to cater to people who hate JS.  There aren't that many of you.
>

There are enough. And it's beside the point anyway. Things that don't need JS sholdn't be using JS anyway, regardless of whether you hate it or have enough brain damage to think it's the greatest thing since the transistor.

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:op.wa1432xjeav7ka@localhost.localdomain...
>
> You may want to consider -- if you on principle don't view pages with information because the pages contain JS, you are the one missing out on the information.
>

And it's not on principle, I just find it not usually worth bothering. I'd rather just move on to something else that's actually well designed. Problem though is when content gets *tied* to such moronic things. Even if 99% of people don't hate JS, these uses of it *are* still moronic bullshit.

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:op.wa16bibneav7ka@localhost.localdomain...
> On Sat, 10 Mar 2012 00:06:40 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> Insert obligatory link: http://drdobbs.com/184401197
>>
>> Very insightful article.
>
> Interesting point to make about D, however.  It's really *difficult* to make related non-member non-friend functions, since all functions inside the same module as a type are friends.

Geez, I *still* keep forgetting about that. And I'm not sure I've ever really found it particularly useful. I'd be happy to see that go away in D3. Acually, I'd argue in favor of changing "private" to "module" (much like how we have the "package" access specifier) and then adding a more traditional private. I doubt any of this will ever actually happen. But, oh well, one can dream.