I read the verdict that the judge wrote, and the impression I got was that the main DMCA violation was _not_ the creating of DeCSS by reverse-engineering, but that once it had been created, it became a 'device for circumventing a technological measure...', and that it was the _trafficking_ of that device (i.e. making it available for download & linking to it) that was the real violation against the DMCA.
The fact that CSS is or is not a trade secret is essentially irrelevant. The fact that no-one has been shown to have used DeCSS for piracy is essentially irrelevant.
DeCSS is a device that was created to circumvent a technological _access_control_ mechanism. The fact that it was made for non-copyright-infringing fair use purposes doesn't matter. It falls into a category of devices that the DMCA outlaws the trafficking of.
"Decoding CDDA is just a format conversion (CDDA -> raw audio)"
So? Using DeCSS is just a format conversion as well. Any form of 'decoding' or 'encoding' can be considered a format conversion. All format conversions can be considered an act of 'encoding' or 'decoding'.
So why can decoding CDDA not be considered 'circumvention of a technological measure'? It does effectively control access to a work. Without the CDDA spec, you can't access the data in a usable format.
It's a unit of weight still used in the UK as well. Only we already have an abbreviation for it - 'lb' (short for libra - latin unit of weight same as a pound).
Plaintiff point:
- It doesn't matter if DeCSS is widely available or not, or whether it is actually used for piracy or not. _If_ (big if) it falls under the title of 'circumvention device', then merely trafficking it (which is what 2600 et. al. freely admit to) is in violation of Section 1201.
Fortunately, it has to be ruled to be a 'circumvention device' (or whatever the wording is - I forget) and not free expression, _and_ it has to be ruled that Section 1201 as currently written does not circumvent 'fair use', which it was not meant to do (But looks like it does) and therefore still stands.
I am really against the MPAA on this, but that is a bastard of a point they have.:(
Someone should organise a 'corporate windows refund day', and try to get as many businesses as possible with as many licenses as possible to attempt to contact their OEM vendor and get refunds for the x-thousand licenses of pre-bundled Windows that they don't need and didn't ask for.
Yeah, we made a bit of a stink about it a while back, but if you get a shitload of other companies asking for thousands of refunds, and pointing out that the EULA says they can, it ought to have quite a bit of clout behind it.
The people setting 'always overwrite' was my point (although it probably got lost in the noise of my post).
If M$ had just put a couple of API calls in Windows that handled DLL installation 5 or 6 years ago, which did version checking _for you_ (and for InstallShield), and _never_ overwrote newer versions, then I think people would be using them, and this problem would be a _lot_ less.
OK, if people start editing the binary to change the version number of a DLL, then that's not going to help, but those people should be shat upon from a great height, and fall into previous category 2. That sort of thing should have a real shitstorm kicked up about it, and generally get people fired if it's commercial.
I have read it, and, IMO, it's totally the wrong approach.
IMO, MS should have implemented a 'install shared file' API a _long_ time ago (like, when Win 3.x was out) when these problems started to become apparent.
The article lists 3 kinds of problems that give you dll hell.
1) Rogue programs overwriting new dlls with older ones.
2) Badly written programs rely on undocumented side-effects or hidden data members that dissappear with new versions.
3) New dlls introduce new bugs.
3 is written off as being minor and unimportant, and for the most part I agree. Any new software can be buggy, and if it is, it should just be patched with an even newer version. This would happen if a new program used a new buggy static library, and so isn't really a dll-only issue.
2 is called the most common cause of dll hell & touted as being the most important reason to change. I say, fuck 'em. If people write programs that rely on undocumented implementation details, as opposed to a published API, then they deserve to have their shit break on them. If you've got a program that breaks when this happens, then give lots of shit to the people that wrote a crappy app, and a patch for that; don't blame the dll writers for changing stuff they never agreed would remain static.
1 is the biggest problem IMO. And it's been around since Win 3.x because updating shared dlls is a pain in the ass. There is no standard way of overwriting shared dlls. If MS has just put in another couple of API calls to install dlls for you, that did all the version checking for you, and set up the auto-copy-on-restart for files in use (that is different for every platform, and a pain to code the first time. I have standard functions for doing this now), and _never_ copied an older file over a newer one, then that would have solved so many problems. By putting auto-version numbering on by default in all their IDEs, this could have been so simple.
I still can't believe that InstallSheild 5.5's default setting for installing files is to overwrite an existing file, whatever the version/date of the original compared to the new one is. That's just sloppy. And if you don't go and check _every_ _single_ file group, and switch them all over to "install only if newer version", then its easy to start overwriting stuff by accident. Yes, it's sloppy not to check it all yourself, I know. But it would be nice to have sensible defaults on the thing.
"I say that unless you use HTTP authentication or another form of validation.. anything you put on a webpage is public-accessible, copyright be damned. It is simply an unreasonable burden to ask otherwise."
I disagree. You can put stuff on a web page, and still maintain effective copyright.
Copyright law is about who maintains distribution rights to a piece of IP. If you put an essay or whatever on your website, and have copyright, all you are effectively saying is that 'here, I'm distributing this for no charge, have a copy'. Which is, as you say, anything you put on a webpage is publicly accessible. Duh!
As a consumer of the IP, you are allowed to make as many copies of the material you want (in your disk cache, mem cache, etc...) provided you do not distribute them to others.
However, this does _not_ mean that anyone else can redistribute your work, as you are the only person who can distribute it, being the copyright holder. Hence linking to any page on the web should be fine, as you're telling people where publically accessible information is, and they're getting a copy from the originating server, as per the copyright holders wishes. But copying a page on to your site and having it open to the public is not legal, as you are distribuiting material that you have no right to, which would seem logical to me. I can't put New York Times articles on my site as I am not allowed to redistribute them. And I'm certainly not allowed to modify them and redistribute them (like changing the byline to read me:)
It would leave caching search engines in trouble, but that's what robots.txt is for.
The other thing, which it is important to note, is that although copyright does protect IP, it does not protect _facts_. So a robot that crawls sites (such as auction sites), _even if it ignores robots.txt_ should be allowed, under existing copyright law, to 'read' the sites, distill whatever facts it wants (such as item prices) from those pages and generate new copyright protected pages with those facts on.
Seems to me that existing copyright law works fine to me (although IANAL) if its interpreted as its spirit was intended.
Heh - reminds me of the secure server room in 'Cryptonomicon'.
Put all your servers in a room with one entrance - a corridor down to a single door. Around the door frame (and behind the plaster) wrap lots of turns of wire, and pass mains electricty through it. Anything in the room is find. Anything outside the room is fine. As soon as any material on magnetic media goes through the doorway, (such as your harddisk which is being removed by government agents) it all goes 'pfft' in a puff of electrons. To get any information to the box directly, you'll need to do it via non-magnetic media (e.g. CD-ROM), or you could just up/down load stuff remotely.
But as soon as the [insert relevant government agency operatives] come along to relocate your equipment for evidence purposes, their act of removing it (and passing it through an alternating magnetic field) causes it to be useless to them.
"Why are you so hung up on where in memory they reside? Who gives a shit if they're "on stack" or "on heap"?"
*sigh*
Because - in the absence of garbage collection, stack based objects are deleted as the stack is unwound.
"Component types aren't based on COM"
Uhhh...let's look at the evidence, shall we?
TComponent methods include:
function _AddRef() : integer; function _Release() : integer; function QueryInterface(iid : TGUID, out obj) : HRESULT;
Looks like IUnknown to me. Hence, it's a COM object. Yeah - they've been protected, so you can't call them from delphi client code. Doesn't mean they're not there though and aren't accessible to other parts of the program.
TComponents are COM objects. They're almost certainly 'classic' ActiveX controls, but I haven't bothered checking whether or not they actually implement all the interfaces required for that. (I say 'classic', as the term 'ActiveX control' has now been expanded to mean pretty much any COM object. Sigh. Don't you love M$? Anyway, I digress...) And if Kylix doens't do COM, as has been mentioned (and not challenged AFAIK), then you're SOOL there then, aren't you?
As for weak references, those are references to objects that are not reference counted.
"Of course [objects] have v-tables, that's what objects are all about"
What??? You've got to be kidding, right?
"Objects", at their most basic, are _ideally_ bits of encapsulated data, whose internal representaion is shielded from the users of said objects by access methods, so that their internal state is always legal.
That does _not_ neccessarily mean function tables, much less v-tables. C++ certainly has the ability to create objects without v-tables, if it's a nice, small, concrete class that you don't expect to be derived further, and has no virtual functions.
I don't actually know how java does OO, but I'm certain that it doesn't do it with v-tables. (I recall someone mentioning it's one of most Java implementations inefficiencies)
What about smalltalk? That's a weakly typed OO langauge and certainly doesn't do polymorphism via v-tables.
What about perl? What exactly is the point in v-tables in an interpreted OO language? You're going through the code, a line at a time, read a function name, and look for a member function with that name. As a string compare. That's not a two-pointer-jump v-table-lookup function call. It's probably going to be implemented along the lines of IDispatch's 'Invoke' method, which is another way of doing polymorphism.
And yes, I can keep track of all my objects, thanks very much. But I like it if the language gives me a hand in doing so. The less I have to worry about such things, the less mistakes I am likely to make (and don't say you've never had a single bug in anything you've ever written) and the more I can get done in a given amount of time.
Look, OO is a design philosophy. It is not tied down to any particular language's representation of it, and can be (and is) implemented in many different ways.
You mean COM interfaces? COM interfaces on COM objects? When Kylix isn't doing COM? Riiight
So, I have the following choices for compound types:
1: 'record' types. POD types. Can be created on stack, or I can 'allocmem' & assign pointer for heap-based records. But no member functions, and certainly no inheritance, unless I want to start contstructing function pointer tables myself, which seems a little excessive.
2: 'class' types. Delphi's own object type, which I can't create on stack. All must be on heap, and must be explicitly '.free'd at end of use. They do have member functions though, and can use inheritance.
3: 'component' types. Based on COM. True object type that is _not_ garbage collected, it is reference counted. Objects created on heap, and free themselves when ref count drops to zero. Must be careful not to make circular references, which will cause objects to stay around for ever. This is hampered by the fact that it is impossible to create weak references to objects. Also, all object must be inherited from TComponent, and all must have v-tables, as well as the ref count and the ref-counting overhead, which I don't neccessarily want for tiny little objects I might have millions of.
I'm sorry, but that's a horrible mish-mash of ways to do things. C++ is bad enough with completely extraneous 'class' keyword doing _exactly_the_same_thing_ as 'struct', except for the default visiblity of members, but aside from that, at least it's pretty consistent.
I've found the features, I just don't like the way they seem to have evolved. I think they'd have been better if they'd been _designed_ with some type of consistency in mind.
Huh? On what basis _would_ you argue for a certain programming language?
(Ideally, the right tool for the right job. However, some people don't have enough time to learn enough languages, in sufficient detail to do the job to their satisfaction, to accomplish this.)
Anyway I wasn't arguing for a programming language anyway. The 'it' I was referring to was the object reference model, which, IMHO, sucks rocks. The rest of the language, for the most part, is fine.
Use TObjectList as a _base_class_? Or a container to store your objects?
Whatever the method, you've still got to remember to free the TObjectList yourself. And you've got t o create one for every new scope. So for every function that uses a local class type variable, you've got to create _another_ object just to hold references to them, and then you've _still_ got to remember to free it yourself anyway.
OK, it makes things slightly better, but I don't think it really invalidates my point. It's a hack to get around a language shortcoming.
As someone who has developed for delphi (although my language of choice is C++, and I have looked at Java + others as well), I have to say I hate the way that Delphi's object model has evolved.
Delphi is based on pascal, and retains pascal's 'record' data capabilities, which are the same as C's 'struct'. It's a compound POD (plain old data - no member functions) type. You create variables of 'record' types as you do any other variable.
So far, so good.
However, the 'object' model sucks rocks.
If you want an object, you create a 'class' object (which is derived from the base 'object' class) and create an instance of that type.
However, you can't create class objects on the stack. You can only create object references. These must set to refer to object created on 'the heap'. And they _must_ be manually deleted. There is no garbage collection, and no reference counting.
Basically, it's the worst of both worlds from Java and C++. You can't even create 'smart references' that would do auto-ref counting, or even just delete objects as the stack unwinds, as those too would be objects, which you'd have to remember to free at the end of your funciton.
Basically, you're looking at potentially worse than c-program memory leaks, as people will prefer to use class types than record types (OO-mania), and stack-based clean-up will go completely.
OK, I can write big programs in C that don't leak memory. But it takes more effort and pains to do so than in C++, which allows me to concentrate on other things more. I fear for some of the memory hogging programs that will come out of Delphi if it gets really 'big'.
If you write a GPL'd program that requires closed libs (either compiler libs or OS libs), then that's OK, because your code is a 'derived work' of those libraries, not the other way around.
If the libs are GPL'd, then you can't link proprietary code to them, which is what the FSF wants. "We'll share our libs with anyone who's willing to share back", but if you write GPL code that needs to be linked to proprietary libs, then that's your perogative as you wrote the code. No-one is 'using' your code as a base, you're using theirs.
I often have over 10 browser windows open at once. Being really used to a slow link (56k modem at home, with pay-per-minute charges in UK) and only a single ISDN at work (but there are only 8 people in the office), I'll tend to load a main news page (such as/., or bluesnews), and for every link that looks interesting I'll 'open in new window', switch back to the main page while that's loading, and repeat as neccessary. Then, when everything's loading nicely, I'll go back to the first article, which should have loaded by now, and read it. Then move onto the next. etc...
If I'm at home, as soon as I see the modem activity drop to 0 for more than 10 seconds, I'll assume everything's loaded & cut the link.
So, first thing in the morning, I'll load up/., load in all the stories (and links to other pages in title blurb on main page) in their own window, and all the interesting BBC SciTech stories (plus whatever else looks good in the slashboxes I've got loaded).
Then I'll have around 20 browser windows open. I'll read one or two things to start with, and then work some, and read the rest when I'm waiting for builds to finish, or having a snack, or 'percolating' to problem solve, etc...
This is on top of MS Dev Studio, Netscape messenger inbox, MSDN, MS VSS, Delphi, Explorer, Bash (under cygwin) plus whatever else I happen to be doing.
Heh heh. I *have* read D&E. It's sitting in front of me (and slightly to the side) on my bookshelf as I type.:)
'include' would rule.
Cross platform ABI? How cross-platform? 32bit/64bit cross platform? And what's the point in a cross platform ABI if the machine code can't be run on separate chips? You take a XP ABId.o file compiled on an x86 with gcc, and copy it straight across to a Mac. Which is also 32-bit. Doesn't matter if the ABIs are the same - the architecture is totally different. So you can read the functions tables (name mangling and all) - what does that get you? You can't execute those functions. You can't link it in with a bunch of other stuff compiled with gcc on the mac - it just won't run.
It's not stupid. It's just doesn't make sense as far as C goes.
C is simple and closely tied to most computer architectures. All C language constructs and operators are designed to be directly implementable in only a few instructions on most CPUs. Hence the basic data types. char, int (various sizes), float (various sizes) & pointers. All CPUs pretty much implement them directly, and not a whole lot else.
Anything else is implemented by (standard) library functions.
You want to implement a string type? That's a job for the library, not the core language. (as it is in C++). How to do that in C? Without C++ classes, and the safety they allow you to implement (destructors, copy constructors) how would you do it in C?
C was written to fulfill a specific purpose. And did it well. And to _not_ have a native string type was (IMO) an _intelligent_ decision based on what C was designed to do, and how it was designed to go about doing it.
Yeah - #include sucks. Hell, cpp (the C preprocessor) sucks. If only Bjarne or the committees had managed to put 'include' in C++, which was, at some point, part of the plan.
One thing I've never liked about what I've read about Python - indentation (whitespace) is part of the semantics. That just makes me shudder.
If I indent a line of code with a tab, and another line of code with 8 spaces, are they part of the same block? Or do I have to use 8 tabs to have the same indentaion as 8 spaces? What if I'm using an editor that has tabs every 4 spaces instead of 8?
IMO C/C++/Java's {/} sytax is much better, and Pascal's begin/end isn't far behind (if a little long-winded)
Slashdot Mirror
I read the verdict that the judge wrote, and the impression I got was that the main DMCA violation was _not_ the creating of DeCSS by reverse-engineering, but that once it had been created, it became a 'device for circumventing a technological measure...', and that it was the _trafficking_ of that device (i.e. making it available for download & linking to it) that was the real violation against the DMCA.
The fact that CSS is or is not a trade secret is essentially irrelevant. The fact that no-one has been shown to have used DeCSS for piracy is essentially irrelevant.
DeCSS is a device that was created to circumvent a technological _access_control_ mechanism. The fact that it was made for non-copyright-infringing fair use purposes doesn't matter. It falls into a category of devices that the DMCA outlaws the trafficking of.
The DMCA just sucks ass is all.
"Decoding CDDA is just a format conversion (CDDA -> raw audio)"
So? Using DeCSS is just a format conversion as well. Any form of 'decoding' or 'encoding' can be considered a format conversion. All format conversions can be considered an act of 'encoding' or 'decoding'.
So why can decoding CDDA not be considered 'circumvention of a technological measure'? It does effectively control access to a work. Without the CDDA spec, you can't access the data in a usable format.
This is _scary_.
Passworded sites? Please explain.
/. with it? (site that requires username/password for non-ac login)
Despite my extensive (or so I thought) web browsing, (these days with mozilla) I'm not really sure what this means.
Do you mean you can't log in to
It's a unit of weight still used in the UK as well. Only we already have an abbreviation for it - 'lb' (short for libra - latin unit of weight same as a pound).
What's wrong with that?
You missed one.
:(
Plaintiff point:
- It doesn't matter if DeCSS is widely available or not, or whether it is actually used for piracy or not. _If_ (big if) it falls under the title of 'circumvention device', then merely trafficking it (which is what 2600 et. al. freely admit to) is in violation of Section 1201.
Fortunately, it has to be ruled to be a 'circumvention device' (or whatever the wording is - I forget) and not free expression, _and_ it has to be ruled that Section 1201 as currently written does not circumvent 'fair use', which it was not meant to do (But looks like it does) and therefore still stands.
I am really against the MPAA on this, but that is a bastard of a point they have.
see _pound_????? Where the hell does that come from?
£ is a pound sign.
# is not. It's a hash mark. Or an octothorpe. Or something else. But certainly not a pound sign.
Someone should organise a 'corporate windows refund day', and try to get as many businesses as possible with as many licenses as possible to attempt to contact their OEM vendor and get refunds for the x-thousand licenses of pre-bundled Windows that they don't need and didn't ask for.
Yeah, we made a bit of a stink about it a while back, but if you get a shitload of other companies asking for thousands of refunds, and pointing out that the EULA says they can, it ought to have quite a bit of clout behind it.
The people setting 'always overwrite' was my point (although it probably got lost in the noise of my post).
If M$ had just put a couple of API calls in Windows that handled DLL installation 5 or 6 years ago, which did version checking _for you_ (and for InstallShield), and _never_ overwrote newer versions, then I think people would be using them, and this problem would be a _lot_ less.
OK, if people start editing the binary to change the version number of a DLL, then that's not going to help, but those people should be shat upon from a great height, and fall into previous category 2. That sort of thing should have a real shitstorm kicked up about it, and generally get people fired if it's commercial.
I have read it, and, IMO, it's totally the wrong approach.
IMO, MS should have implemented a 'install shared file' API a _long_ time ago (like, when Win 3.x was out) when these problems started to become apparent.
The article lists 3 kinds of problems that give you dll hell.
1) Rogue programs overwriting new dlls with older ones.
2) Badly written programs rely on undocumented side-effects or hidden data members that dissappear with new versions.
3) New dlls introduce new bugs.
3 is written off as being minor and unimportant, and for the most part I agree. Any new software can be buggy, and if it is, it should just be patched with an even newer version. This would happen if a new program used a new buggy static library, and so isn't really a dll-only issue.
2 is called the most common cause of dll hell & touted as being the most important reason to change. I say, fuck 'em. If people write programs that rely on undocumented implementation details, as opposed to a published API, then they deserve to have their shit break on them. If you've got a program that breaks when this happens, then give lots of shit to the people that wrote a crappy app, and a patch for that; don't blame the dll writers for changing stuff they never agreed would remain static.
1 is the biggest problem IMO. And it's been around since Win 3.x because updating shared dlls is a pain in the ass. There is no standard way of overwriting shared dlls. If MS has just put in another couple of API calls to install dlls for you, that did all the version checking for you, and set up the auto-copy-on-restart for files in use (that is different for every platform, and a pain to code the first time. I have standard functions for doing this now), and _never_ copied an older file over a newer one, then that would have solved so many problems. By putting auto-version numbering on by default in all their IDEs, this could have been so simple.
I still can't believe that InstallSheild 5.5's default setting for installing files is to overwrite an existing file, whatever the version/date of the original compared to the new one is. That's just sloppy. And if you don't go and check _every_ _single_ file group, and switch them all over to "install only if newer version", then its easy to start overwriting stuff by accident. Yes, it's sloppy not to check it all yourself, I know. But it would be nice to have sensible defaults on the thing.
"I say that unless you use HTTP authentication or another form of validation.. anything you put on a webpage is public-accessible, copyright be damned. It is simply an unreasonable burden to ask otherwise."
:)
I disagree. You can put stuff on a web page, and still maintain effective copyright.
Copyright law is about who maintains distribution rights to a piece of IP. If you put an essay or whatever on your website, and have copyright, all you are effectively saying is that 'here, I'm distributing this for no charge, have a copy'. Which is, as you say, anything you put on a webpage is publicly accessible. Duh!
As a consumer of the IP, you are allowed to make as many copies of the material you want (in your disk cache, mem cache, etc...) provided you do not distribute them to others.
However, this does _not_ mean that anyone else can redistribute your work, as you are the only person who can distribute it, being the copyright holder. Hence linking to any page on the web should be fine, as you're telling people where publically accessible information is, and they're getting a copy from the originating server, as per the copyright holders wishes. But copying a page on to your site and having it open to the public is not legal, as you are distribuiting material that you have no right to, which would seem logical to me. I can't put New York Times articles on my site as I am not allowed to redistribute them. And I'm certainly not allowed to modify them and redistribute them (like changing the byline to read me
It would leave caching search engines in trouble, but that's what robots.txt is for.
The other thing, which it is important to note, is that although copyright does protect IP, it does not protect _facts_. So a robot that crawls sites (such as auction sites), _even if it ignores robots.txt_ should be allowed, under existing copyright law, to 'read' the sites, distill whatever facts it wants (such as item prices) from those pages and generate new copyright protected pages with those facts on.
Seems to me that existing copyright law works fine to me (although IANAL) if its interpreted as its spirit was intended.
Copyright is good.
Heh - reminds me of the secure server room in 'Cryptonomicon'.
Put all your servers in a room with one entrance - a corridor down to a single door. Around the door frame (and behind the plaster) wrap lots of turns of wire, and pass mains electricty through it. Anything in the room is find. Anything outside the room is fine. As soon as any material on magnetic media goes through the doorway, (such as your harddisk which is being removed by government agents) it all goes 'pfft' in a puff of electrons. To get any information to the box directly, you'll need to do it via non-magnetic media (e.g. CD-ROM), or you could just up/down load stuff remotely.
But as soon as the [insert relevant government agency operatives] come along to relocate your equipment for evidence purposes, their act of removing it (and passing it through an alternating magnetic field) causes it to be useless to them.
tada!
"Why are you so hung up on where in memory they reside? Who gives a shit if they're "on stack" or "on heap"?"
*sigh*
Because - in the absence of garbage collection, stack based objects are deleted as the stack is unwound.
"Component types aren't based on COM"
Uhhh...let's look at the evidence, shall we?
TComponent methods include:
function _AddRef() : integer;
function _Release() : integer;
function QueryInterface(iid : TGUID, out obj) : HRESULT;
Looks like IUnknown to me. Hence, it's a COM object. Yeah - they've been protected, so you can't call them from delphi client code. Doesn't mean they're not there though and aren't accessible to other parts of the program.
TComponents are COM objects. They're almost certainly 'classic' ActiveX controls, but I haven't bothered checking whether or not they actually implement all the interfaces required for that. (I say 'classic', as the term 'ActiveX control' has now been expanded to mean pretty much any COM object. Sigh. Don't you love M$? Anyway, I digress...) And if Kylix doens't do COM, as has been mentioned (and not challenged AFAIK), then you're SOOL there then, aren't you?
As for weak references, those are references to objects that are not reference counted.
"Of course [objects] have v-tables, that's what objects are all about"
What??? You've got to be kidding, right?
"Objects", at their most basic, are _ideally_ bits of encapsulated data, whose internal representaion is shielded from the users of said objects by access methods, so that their internal state is always legal.
That does _not_ neccessarily mean function tables, much less v-tables. C++ certainly has the ability to create objects without v-tables, if it's a nice, small, concrete class that you don't expect to be derived further, and has no virtual functions.
I don't actually know how java does OO, but I'm certain that it doesn't do it with v-tables. (I recall someone mentioning it's one of most Java implementations inefficiencies)
What about smalltalk? That's a weakly typed OO langauge and certainly doesn't do polymorphism via v-tables.
What about perl? What exactly is the point in v-tables in an interpreted OO language? You're going through the code, a line at a time, read a function name, and look for a member function with that name. As a string compare. That's not a two-pointer-jump v-table-lookup function call. It's probably going to be implemented along the lines of IDispatch's 'Invoke' method, which is another way of doing polymorphism.
And yes, I can keep track of all my objects, thanks very much. But I like it if the language gives me a hand in doing so. The less I have to worry about such things, the less mistakes I am likely to make (and don't say you've never had a single bug in anything you've ever written) and the more I can get done in a given amount of time.
Look, OO is a design philosophy. It is not tied down to any particular language's representation of it, and can be (and is) implemented in many different ways.
What if you link to an off-shore site that doesn't contain info about drugs, but contains an immediate re-direct to one that does?
They can't manage to outlaw linking to sites that link to sites with information, can they? That would just make the whole web illegal.
(Which isn't to say that making you responsible for what on the other end of _any_ link isn't dumb)
You mean COM interfaces? COM interfaces on COM objects? When Kylix isn't doing COM? Riiight
So, I have the following choices for compound types:
1: 'record' types. POD types. Can be created on stack, or I can 'allocmem' & assign pointer for heap-based records. But no member functions, and certainly no inheritance, unless I want to start contstructing function pointer tables myself, which seems a little excessive.
2: 'class' types. Delphi's own object type, which I can't create on stack. All must be on heap, and must be explicitly '.free'd at end of use. They do have member functions though, and can use inheritance.
3: 'component' types. Based on COM. True object type that is _not_ garbage collected, it is reference counted. Objects created on heap, and free themselves when ref count drops to zero. Must be careful not to make circular references, which will cause objects to stay around for ever. This is hampered by the fact that it is impossible to create weak references to objects. Also, all object must be inherited from TComponent, and all must have v-tables, as well as the ref count and the ref-counting overhead, which I don't neccessarily want for tiny little objects I might have millions of.
I'm sorry, but that's a horrible mish-mash of ways to do things. C++ is bad enough with completely extraneous 'class' keyword doing _exactly_the_same_thing_ as 'struct', except for the default visiblity of members, but aside from that, at least it's pretty consistent.
I've found the features, I just don't like the way they seem to have evolved. I think they'd have been better if they'd been _designed_ with some type of consistency in mind.
Huh? On what basis _would_ you argue for a certain programming language?
(Ideally, the right tool for the right job. However, some people don't have enough time to learn enough languages, in sufficient detail to do the job to their satisfaction, to accomplish this.)
Anyway I wasn't arguing for a programming language anyway. The 'it' I was referring to was the object reference model, which, IMHO, sucks rocks. The rest of the language, for the most part, is fine.
Huh?
Use TObjectList as a _base_class_? Or a container to store your objects?
Whatever the method, you've still got to remember to free the TObjectList yourself. And you've got t o create one for every new scope. So for every function that uses a local class type variable, you've got to create _another_ object just to hold references to them, and then you've _still_ got to remember to free it yourself anyway.
OK, it makes things slightly better, but I don't think it really invalidates my point. It's a hack to get around a language shortcoming.
As someone who has developed for delphi (although my language of choice is C++, and I have looked at Java + others as well), I have to say I hate the way that Delphi's object model has evolved.
Delphi is based on pascal, and retains pascal's 'record' data capabilities, which are the same as C's 'struct'. It's a compound POD (plain old data - no member functions) type. You create variables of 'record' types as you do any other variable.
So far, so good.
However, the 'object' model sucks rocks.
If you want an object, you create a 'class' object (which is derived from the base 'object' class) and create an instance of that type.
However, you can't create class objects on the stack. You can only create object references. These must set to refer to object created on 'the heap'. And they _must_ be manually deleted. There is no garbage collection, and no reference counting.
Basically, it's the worst of both worlds from Java and C++. You can't even create 'smart references' that would do auto-ref counting, or even just delete objects as the stack unwinds, as those too would be objects, which you'd have to remember to free at the end of your funciton.
Basically, you're looking at potentially worse than c-program memory leaks, as people will prefer to use class types than record types (OO-mania), and stack-based clean-up will go completely.
OK, I can write big programs in C that don't leak memory. But it takes more effort and pains to do so than in C++, which allows me to concentrate on other things more. I fear for some of the memory hogging programs that will come out of Delphi if it gets really 'big'.
K.
I thought we'd been over this before.
If you write a GPL'd program that requires closed libs (either compiler libs or OS libs), then that's OK, because your code is a 'derived work' of those libraries, not the other way around.
If the libs are GPL'd, then you can't link proprietary code to them, which is what the FSF wants. "We'll share our libs with anyone who's willing to share back", but if you write GPL code that needs to be linked to proprietary libs, then that's your perogative as you wrote the code. No-one is 'using' your code as a base, you're using theirs.
K.
Nope. That's the first thing I thought of too.
I often have over 10 browser windows open at once. Being really used to a slow link (56k modem at home, with pay-per-minute charges in UK) and only a single ISDN at work (but there are only 8 people in the office), I'll tend to load a main news page (such as /., or bluesnews), and for every link that looks interesting I'll 'open in new window', switch back to the main page while that's loading, and repeat as neccessary. Then, when everything's loading nicely, I'll go back to the first article, which should have loaded by now, and read it. Then move onto the next. etc...
/., load in all the stories (and links to other pages in title blurb on main page) in their own window, and all the interesting BBC SciTech stories (plus whatever else looks good in the slashboxes I've got loaded).
If I'm at home, as soon as I see the modem activity drop to 0 for more than 10 seconds, I'll assume everything's loaded & cut the link.
So, first thing in the morning, I'll load up
Then I'll have around 20 browser windows open. I'll read one or two things to start with, and then work some, and read the rest when I'm waiting for builds to finish, or having a snack, or 'percolating' to problem solve, etc...
This is on top of MS Dev Studio, Netscape messenger inbox, MSDN, MS VSS, Delphi, Explorer, Bash (under cygwin) plus whatever else I happen to be doing.
Alt+Tab is my friend. As are tooltips.
Heh heh. I *have* read D&E. It's sitting in front of me (and slightly to the side) on my bookshelf as I type. :)
.o file compiled on an x86 with gcc, and copy it straight across to a Mac. Which is also 32-bit.
'include' would rule.
Cross platform ABI? How cross-platform? 32bit/64bit cross platform? And what's the point in a cross platform ABI if the machine code can't be run on separate chips? You take a XP ABId
Doesn't matter if the ABIs are the same - the architecture is totally different. So you can read the functions tables (name mangling and all) - what does that get you? You can't execute those functions. You can't link it in with a bunch of other stuff compiled with gcc on the mac - it just won't run.
As Bjorn Stenborg pointed out - how are you supposed to write a script to autoindent a source file which gives no clues where blocks begin and end?
It's not stupid. It's just doesn't make sense as far as C goes.
C is simple and closely tied to most computer architectures. All C language constructs and operators are designed to be directly implementable in only a few instructions on most CPUs. Hence the basic data types. char, int (various sizes), float (various sizes) & pointers. All CPUs pretty much implement them directly, and not a whole lot else.
Anything else is implemented by (standard) library functions.
You want to implement a string type? That's a job for the library, not the core language. (as it is in C++). How to do that in C? Without C++ classes, and the safety they allow you to implement (destructors, copy constructors) how would you do it in C?
C was written to fulfill a specific purpose. And did it well. And to _not_ have a native string type was (IMO) an _intelligent_ decision based on what C was designed to do, and how it was designed to go about doing it.
K.
Yeah - #include sucks. Hell, cpp (the C preprocessor) sucks. If only Bjarne or the committees had managed to put 'include' in C++, which was, at some point, part of the plan.
Then we'd have almost entirely got rid of cpp.
Sigh
One thing I've never liked about what I've read about Python - indentation (whitespace) is part of the semantics. That just makes me shudder.
If I indent a line of code with a tab, and another line of code with 8 spaces, are they part of the same block? Or do I have to use 8 tabs to have the same indentaion as 8 spaces? What if I'm using an editor that has tabs every 4 spaces instead of 8?
IMO C/C++/Java's {/} sytax is much better, and Pascal's begin/end isn't far behind (if a little long-winded)
What does perl use?