OOD is a paradigm that evolved 30 years ago and, today, is more popular than ever.
You seem convinced in your own ability to appraise its worthiness, and you have done so.
You at once seem eager to sample everything offered to you, and eager to eliminate huge swaths of what's presented based only on your own bias.
Not once have I expressed my opinion about what paradigm is best for anything. You seem concerned about nothing else than what you feel is "best."
At first it seemed like you were interested in a back and forth about the merits of a technique that is arguably the most popular in software development today.
I didn't expect to "convince you" of anything. What I did expect was a discussion of merits, and not a fixation upon your own personal bias.
I suppose I Should've known better based solely on how you first presented yourself, belicose with the "hold on, some of us..." comment.
As a software developer, there's nothing I hate more when I see or hear it than assumptions. You've built quite a little comfort zone for yourself inside your assumptions.
What you are missing, though, is that you're only handicapping yourself. By refusing to use a common tool in todays web-development tool box, you're doing nothing but boxing yourself in and limiting your own earnings potential.
What I'm getting at is that you're argument is far too faith-based with far too much belief in your own dogma.
There is nothing you've written that hasn't been argued by people smarter than either of us, at length, as far back as the 1970s.
None of your points matter to me, because I'm not looking for purity or dogma. I'm looking for the best tool to do any given job. And I'm not letting personal bias get in the way of that.
You've elevated "Procedural Design" to religion in your own mind, replete with "I'm telling you the truth, dude" logic that I can hear on any NYC street corner.
It's too bad. For a moment, a couple posts upthread, I thought you were genuinely open to new ideas and egalitarian discourse.
I'm curious: Have you ever used a fully OO language?
If not, and if you really have intellectual curiosity, you should go download Visual C# Express (for free) and get a C# book (for $40).
In a fully OO language, which PHP is not, everything is an object. So, when you initialize a string, it's actually an object. You can dig down and find the String class definition. You can extend the class. Etc.
The fact that you used the word "Subclass" makes me think you come from, perhaps, a Visual Basic background. (Ditto your use of "Setters" and "Getters" that you mentioned in an earlier post). I did a lot of VB6 work some years back, too, so this isn't a dig. I'm just curious.
Because when you're using an OO language, and you begin to think in terms of "Everything is an Object" you'd be surprised how natural it can feel.
And you knock the textbook examples, but the thing is, they are accurate. Software is often about modeling real-world problems and phenomena.
It's not just abotu levels of abstraction, it's about increasing levels of specification.
Here's a textbook example that has the benefit of being a real-world problem:
HTML Forms are an easy target, because they're just consistent enough to be able to abstract away, and because they're just a big enough PITA to want to.
It just so happens, that this is a really great example of inheritance and polymorphism.
First, there's going to be a class that represents the form itself. It has data -- the action, method, form name, dom ID, etc. And it has behaviors -- render(), loadFromPost(), etc.
It also holds a collection of Input objects.
So we create a class called Input. It holds all the logic that is common to every HTML form control, [input], [select], etc.
And it also exposes some abstract functions, which means that there is no CODE in these functions in this class, it just lists the function definition, and it's the job of the extending classes to supply the implementation. Abstract functions in this class would be, say, render(), setDefaultValue() and getValue().
Then we'd have a TextInput class Extends Input. PasswordInput and TextareaInput would extend TextInput. SelectInput would extend Input, and perhaps MultiSelectInput would extend that.
And at a lower level, you can get really cool:
EmailInput extends TextInput, DateInput extends TextInput, etc.
Each of these fields is rendered in slightly different ways. They share many traits, but are also unique in many ways.
With an object heirarchy of this type, all shared logic lives in a shared point of generalization. Each extending class (aka subclass) adds a further level of specification.
And the beauty of this is that when the form is submitted, and the object hierarchy is reconstructed in memory (most likely it was just put to sleep, so to speak), you can load all the field objects into an array.
And you can do something like this:
foreach ($fields as $field) {
if ($field->validate())
{
$dataModel->importValue($field->value());
}
else
{// Throw Exception
} }
And in this loop, we don't have to worry about what kind of field it is. We don't have to worry about what validate() is doing. We don't even have to worry if there IS no validate() method on the specified class, because if there isn't, it'll inherit the validate() method from a more general level.
Same with getValue(). Or, on the form-render side, the setDefaultValue(). It doesn't matter to us that checkboxes, selects, inputs, etc, will all set values in a different way.
And the truth is that you may make some blanket claim like "OO Heirarchies don't work with domain problems" but that's just not true.
Because when you think not in terms of levels of abs
What I'm taken aback by is that you don't seem to disagree with the OOD Theory. You seem to just not 'get it.'
First, the post I wrote was far longer than anybody else who had replied at the time of my writing this. There's only so much you can ask for in a comment on a message board. There are dozens of BOOKS on this topic, as somebody else mentioned,
That being said, here's the part it seems you just dont "get."
The difference between procedural "encapsulation" and object encapsulation is about behaviors.
In procedural code, the behavior and the data structure are separate. You can have, say, an array to hold data. And then a series of related-but-not-connected procedures ("behaviors") that act upon it.
In OO code, the object contains the data (perhaps using array(s) as well) AND the behaviors.
Take the language examples I gave. When an array is a first-class object, as it is in any complete OO language, it exposes not just the ability to store data, it also exposes common behavior: push, pop, sort, ksort. And it also exposes metadata such as size.
In a procedural language, these behaviors are all isolated from the data structure itself. The only thing connecting them is documentation.
So, in PHPs function library, if you want to see what behaviors are available for an array, the only way to see a truly complete list is to hope that the documentation is up to date.
In a complete OO language (Java, any.Net language, etc), there is an Array class. You can look at it. ALL of the behaviors are right there, in the class.
The same principle holds true in the data types you create in an application.
And to tie in to how I began this post... it sounds like you're not disagreeing with tying behavior to data. It sounds like you just don't get it.
How about this... you want examples of "good" OO web apps?
Tell me this..
What is there about "operating systems and systems software" that can benefit from OOD that isn't there in web apps?
I've never seen a procedural CRUD app that couldn't be done better with a data Model.
With a Model I can contain ALL logic for creating, updating, retrieving and deleting records, with a single point of user authentication and data validation. That's worth it's weight in gold.
You specifically mention e-commerce.
So think of a Products table. Chances are, you'll be using Product data on nearly every single page in your app.
In one corner is procedural code, where you have to worry about the implementation of the Products table on pages like the "review your order" or "similar items." That is, I have to think about (and hard-code into SQL strings) the names of columns in the product table. I have to pollute every single page with implementation details of the product table. You change the schema, you have to find every page that touches that table and update it.
An example:
$sql = 'Select productName, productDescription, proudctPrice from products where product = ' . $id;
In the opposing corner is OOD. I would create a products Model. Once. I would write one set of SQL strings. Once. And use my "api" from then on.
An example:
$product = new Products($id);
Now, that's implementation. How about the language itself?
Procedural code: You have an array? What's the size? you have to use the count() method (or sizeof()). You have a string? You have to use strlen(). You want to add 2 dates together? You have to convert to timestamps and then add and then convert back to a string-date for readability.
It's about logical organization. Layers of increased specificity. Abstractions that eliminate the need to worry about the unnecessary at any given level.
I started my career as a procedural developer. Learning, really learning OOD was way more difficult than just learning a new language is. But it's worth it. I would never go back. Not for web apps. Not for rich client apps. No way.
You can type CAST in php4 but you can't type HINT.
And I would also disagree that eval() is any sort of substitute for try..catch blocks. The real leap forward wrt error handling wasn't so much try..catch, it was the fact that exceptions were added to the language, which is the whole point of try..catch (to catch a thrown exception).
In practice, however, most PHP4 code will run perfectly fine on PHP5, with the interpreter throwing only E_NOTICE warnings about access control modifiers and such.
It can be hit-and-miss. 99% of fatal errors I've encountered during migration processes are apps that have a class that, in PHP5, creates a namespace collision with the PHP5 Standard Library.
In some cases the change from objects being passed byval to byref causes issues when the developer was counting on the object being passed byval.
But that's very rare. It's hard to even dream-up an example where things break when you pass an object byref.
The PHP folks have taken care to TRY to prevent apps from breaking during the migration process.
Things like supporting both the new keyword-based-constructors AND the old "magic coincidental naming" based constructors.
And funny enough... if you wait to upgrade your PHP4 apps until 5.3 is realsed (it's in Alpha right now), you might not have very many problems at all. Namespaces are finally introduced in 5.3 and one would think that platform libraries will be in their own namespace, preventing the collisions I mentioned earlier.
One of my fave's was the fliers in 2004 in inner-city neighborhoods that said things like:
"Remember, to be eligible to vote your Rent and Utility Bills must be paid"
And this is why the 50 State Strategy that Howard Dean has advocated as the Chairman of the Democratic Party is important.
And it's a brilliant stroke of luck for Democrats that we have a candidate with the desire, funding and appeal to implement Dean's strategy.
We NEED to run everywhere. We NEED to have a deep bench. We NEED Democrats running city halls and city councils, we NEED Democrats in county and state level government.
We need a deep bench and we need to have at least as much control over redistricting, election law, ballot access, etc, as the GOP.
that or invalidate the election results and hold a new election in Florida with ballots designed according to a national standard
While that seems obvious, it's really not possible. Not only is it really f'in expensive to hold an election in a state as large as Florida, it's also in the US constitution that all states will vote for the President on the same day.
Also, in 2000, it wasn't as clean cut as "well, let's stop playing the game now and whoever's in front, wins."
There's only about 100 days between the election and the inauguration. Electors had to cast votes and those votes had to be certified by the congress. And a deadline, the law of the land, was approaching. Above all, peaceful transition of power is the most important thing.
The Florida Supreme Court and the US Supreme Court both granted "victories" to the Democrats, allowing counties to perform recounts.
The real injustice was on the ground, not in the courtroom.
Since there was a deadline, and the process of hand recounts allowed either party to object to the disposition of any given ballot, all the GOP operatives had to do was object to every vote that was determined to be a Gore vote.
This slowed things down so much that there simply was no way to perform a recount in the time given.
I'm sure this strategy wasn't harmed by the fact that George Bush's brother was the Governor of Florida at the time and the GOP secretary of state was a party hack.
If you RTFA you'd see that the so-called attacker claims this is "far reaching" and affects more than Microsoft.
The "Shatter Attack" was just an exploit of the inter-process message queue.
And to answer the guy above me, yes, the flaw is fixed in Vista, and there's also a trip-wire to detect this behavior in the event that another flaw is found.
I think that's the GP's point. Vista's IE settings are "correctly configured" "out-of-the-box."
I know, I know, you have some story about how Vista totally sucks and it's personally responsible for killing 300 people in march, 1968 in the Mekong Delta....
But, as a professional software developer, I think Vista security is actually quite good. It's easy to blast UAC if you don't care about or understand the social-engineering behind it.
Exactly. It's saber rattling. Sounds like nothing more.
Furthermore, I love how silly some people here can be. The article says:
far-reaching implications not only for Microsoft
But somehow this is a Vista security issue?
Please. Many here on this site, and many articles posted here, have a bias. There's nothing wrong with that, most things in life have a bias in some way.
But there's a difference between "bias" and "intellectual dishonesty."
It doesn't matter what Blu Ray offers. That's my whole point in my OP.
That's the reason this study is ass backwards.
A Blu Ray player does not drive your TV purchase. Your HD TV drives your Blu Ray purchase.
If you have an HDTV, even a semi-HD 720P set, you're going to want to get your money out of it.
The fact that your TV does not "fully exercise" the Blu Ray player is moot.
Because the Blu Ray player will "fully exercise" the capabilities of your 720p TV.
As a matter of fact, I have a 720p Toshiba in my bedroom and a 1080p Samsung in my living room. I've watched Blu Ray on both.
No doubt, it looks better on 1080, but that's also perhaps the 120hz refresh rate.
But Blu Ray looks FAR BETTER on my 720 set than ANYTHING ELSE.
Better than the HD channels on my Cable (And I have a very good local cable company with a high-bandwidth system that doesn't over-compress HD channels like Comcast does).
Better than the OTA HD.
WAY better than up-converted SD DVD.
Look.. the crux of this argument is you saying that, on balance, consumers will do X.
The crux of MY argument is just logical and anecdotal:
1. Logically, this study is meaningless and ergo any inferences drawn are meaningless. Blu Ray is a HORRIBLE proposition for somebody who currently has a SD TV with no immediate plans to upgrade.
Nobody is going to buy a new TV just to get a new DVD technology. But once you have that TV that you dropped $$ on, you want to get the max out of it.
2. Anecdotally, everyone I know that has an HDTV has or wants to buy a Blu Ray player (Or, previously, some surely wanted HD-DVD).
It would be like saying "I have no plans on buying a Stereo TV" or "I have no plans on buying a Color TV"
Eventually those 2 technologies became so ubiquitous that it doesn't matter that you may not care about them.
Sure, you can by mono and/or B&W TV's, but not if you want a TV of any normal size for a living room.
SD TVs will slowly fade out. And like most technologies, there will be a point where an SD TV costs MORE than an HD TV. Just like you can often get a DVD player now for less than VHS.
It's just about mass production.
And when you have an HD TV, well, you strangely want to make the most of your technology. BluRay is natural for HDTV Owners.
And that's why this study is silly. OF COURSE people are not receptive to an off-the-cuff $1500 purchase of a Blu Ray and the HDTV necessary to make proper use of it.
The actual cost of the warranty repairs could end up breaking-even for Apple. In which case, they'd be making profit from pooling together everyones warranty money and earning 3-10% annually on it. Especially during the first couple years when things are likely not failing.
If they did this and earned an average of, say, 7% annually, and they compound the interest, they'd make about $40 per warranty over the first 3 years.
And I think it's safe to say that as an Apple customer, if you didn't plunk down $170 on that warranty, chances are you're not going to invest that money in your IRA instead.
I'm not trying to be a "know it all" about this, and I have no idea if Apple is actually doing this. But this is how insurance companies work, and all a warranty is, is an insurance policy. So it makes sense to me.
One more thing: Whenever you see a plant close, you see regular folks on the local News, talking about how they're devestated to lose the job that paid them, oh, $27/hr plus OT for screwing in a bolt 900 times per shift.
They always say the same thing: "I just don't think I'll be able to make this much money anywhere else."
Here's a clue: If nobody else will pay you your existing wage for your existing skills, that means you are being overpaid.
Slashdot Mirror
OOD is a paradigm that evolved 30 years ago and, today, is more popular than ever.
You seem convinced in your own ability to appraise its worthiness, and you have done so.
You at once seem eager to sample everything offered to you, and eager to eliminate huge swaths of what's presented based only on your own bias.
Not once have I expressed my opinion about what paradigm is best for anything. You seem concerned about nothing else than what you feel is "best."
At first it seemed like you were interested in a back and forth about the merits of a technique that is arguably the most popular in software development today.
I didn't expect to "convince you" of anything. What I did expect was a discussion of merits, and not a fixation upon your own personal bias.
I suppose I Should've known better based solely on how you first presented yourself, belicose with the "hold on, some of us..." comment.
As a software developer, there's nothing I hate more when I see or hear it than assumptions. You've built quite a little comfort zone for yourself inside your assumptions.
What you are missing, though, is that you're only handicapping yourself. By refusing to use a common tool in todays web-development tool box, you're doing nothing but boxing yourself in and limiting your own earnings potential.
What I'm getting at is that you're argument is far too faith-based with far too much belief in your own dogma.
There is nothing you've written that hasn't been argued by people smarter than either of us, at length, as far back as the 1970s.
None of your points matter to me, because I'm not looking for purity or dogma. I'm looking for the best tool to do any given job. And I'm not letting personal bias get in the way of that.
You've elevated "Procedural Design" to religion in your own mind, replete with "I'm telling you the truth, dude" logic that I can hear on any NYC street corner.
It's too bad. For a moment, a couple posts upthread, I thought you were genuinely open to new ideas and egalitarian discourse.
Good luck. But I'm done with this thread.
I'm curious: Have you ever used a fully OO language?
If not, and if you really have intellectual curiosity, you should go download Visual C# Express (for free) and get a C# book (for $40).
In a fully OO language, which PHP is not, everything is an object. So, when you initialize a string, it's actually an object. You can dig down and find the String class definition. You can extend the class. Etc.
The fact that you used the word "Subclass" makes me think you come from, perhaps, a Visual Basic background. (Ditto your use of "Setters" and "Getters" that you mentioned in an earlier post). I did a lot of VB6 work some years back, too, so this isn't a dig. I'm just curious.
Because when you're using an OO language, and you begin to think in terms of "Everything is an Object" you'd be surprised how natural it can feel.
And you knock the textbook examples, but the thing is, they are accurate. Software is often about modeling real-world problems and phenomena.
It's not just abotu levels of abstraction, it's about increasing levels of specification.
Here's a textbook example that has the benefit of being a real-world problem:
HTML Forms are an easy target, because they're just consistent enough to be able to abstract away, and because they're just a big enough PITA to want to.
It just so happens, that this is a really great example of inheritance and polymorphism.
First, there's going to be a class that represents the form itself. It has data -- the action, method, form name, dom ID, etc. And it has behaviors -- render(), loadFromPost(), etc.
It also holds a collection of Input objects.
So we create a class called Input. It holds all the logic that is common to every HTML form control, [input], [select], etc.
And it also exposes some abstract functions, which means that there is no CODE in these functions in this class, it just lists the function definition, and it's the job of the extending classes to supply the implementation. Abstract functions in this class would be, say, render(), setDefaultValue() and getValue().
Then we'd have a TextInput class Extends Input. PasswordInput and TextareaInput would extend TextInput. SelectInput would extend Input, and perhaps MultiSelectInput would extend that.
And at a lower level, you can get really cool:
EmailInput extends TextInput, DateInput extends TextInput, etc.
Each of these fields is rendered in slightly different ways. They share many traits, but are also unique in many ways.
With an object heirarchy of this type, all shared logic lives in a shared point of generalization. Each extending class (aka subclass) adds a further level of specification.
And the beauty of this is that when the form is submitted, and the object hierarchy is reconstructed in memory (most likely it was just put to sleep, so to speak), you can load all the field objects into an array.
And you can do something like this:
And in this loop, we don't have to worry about what kind of field it is. We don't have to worry about what validate() is doing. We don't even have to worry if there IS no validate() method on the specified class, because if there isn't, it'll inherit the validate() method from a more general level.
Same with getValue(). Or, on the form-render side, the setDefaultValue(). It doesn't matter to us that checkboxes, selects, inputs, etc, will all set values in a different way.
And the truth is that you may make some blanket claim like "OO Heirarchies don't work with domain problems" but that's just not true.
Because when you think not in terms of levels of abs
What I'm taken aback by is that you don't seem to disagree with the OOD Theory. You seem to just not 'get it.'
First, the post I wrote was far longer than anybody else who had replied at the time of my writing this. There's only so much you can ask for in a comment on a message board. There are dozens of BOOKS on this topic, as somebody else mentioned,
That being said, here's the part it seems you just dont "get."
The difference between procedural "encapsulation" and object encapsulation is about behaviors.
In procedural code, the behavior and the data structure are separate. You can have, say, an array to hold data. And then a series of related-but-not-connected procedures ("behaviors") that act upon it.
In OO code, the object contains the data (perhaps using array(s) as well) AND the behaviors.
Take the language examples I gave. When an array is a first-class object, as it is in any complete OO language, it exposes not just the ability to store data, it also exposes common behavior: push, pop, sort, ksort. And it also exposes metadata such as size.
In a procedural language, these behaviors are all isolated from the data structure itself. The only thing connecting them is documentation.
So, in PHPs function library, if you want to see what behaviors are available for an array, the only way to see a truly complete list is to hope that the documentation is up to date.
In a complete OO language (Java, any .Net language, etc), there is an Array class. You can look at it. ALL of the behaviors are right there, in the class.
The same principle holds true in the data types you create in an application.
And to tie in to how I began this post... it sounds like you're not disagreeing with tying behavior to data. It sounds like you just don't get it.
How about this... you want examples of "good" OO web apps?
Tell me this..
What is there about "operating systems and systems software" that can benefit from OOD that isn't there in web apps?
I've never seen a procedural CRUD app that couldn't be done better with a data Model.
With a Model I can contain ALL logic for creating, updating, retrieving and deleting records, with a single point of user authentication and data validation. That's worth it's weight in gold.
You specifically mention e-commerce.
So think of a Products table. Chances are, you'll be using Product data on nearly every single page in your app.
In one corner is procedural code, where you have to worry about the implementation of the Products table on pages like the "review your order" or "similar items." That is, I have to think about (and hard-code into SQL strings) the names of columns in the product table. I have to pollute every single page with implementation details of the product table. You change the schema, you have to find every page that touches that table and update it.
An example:
In the opposing corner is OOD. I would create a products Model. Once. I would write one set of SQL strings. Once. And use my "api" from then on.
An example:
Now, that's implementation. How about the language itself?
Procedural code:
You have an array? What's the size? you have to use the count() method (or sizeof()). You have a string? You have to use strlen(). You want to add 2 dates together? You have to convert to timestamps and then add and then convert back to a string-date for readability.
OO Code:
The size of an array?
The size of a string?
Add two dates?
How about reading a file?
Procedural:
OO:
It's about encapsulation.
Imagine I was writing the software for you.
If this is OO software, and I want to know your eye color, I ask you:
In procedural code, I have to ask somebody else to ask you:
It's about logical organization. Layers of increased specificity. Abstractions that eliminate the need to worry about the unnecessary at any given level.
I started my career as a procedural developer. Learning, really learning OOD was way more difficult than just learning a new language is. But it's worth it. I would never go back. Not for web apps. Not for rich client apps. No way.
You can type CAST in php4 but you can't type HINT.
And I would also disagree that eval() is any sort of substitute for try..catch blocks. The real leap forward wrt error handling wasn't so much try..catch, it was the fact that exceptions were added to the language, which is the whole point of try..catch (to catch a thrown exception).
But I agree with everything else you said.
In practice, however, most PHP4 code will run perfectly fine on PHP5, with the interpreter throwing only E_NOTICE warnings about access control modifiers and such.
It can be hit-and-miss. 99% of fatal errors I've encountered during migration processes are apps that have a class that, in PHP5, creates a namespace collision with the PHP5 Standard Library.
In some cases the change from objects being passed byval to byref causes issues when the developer was counting on the object being passed byval.
But that's very rare. It's hard to even dream-up an example where things break when you pass an object byref.
The PHP folks have taken care to TRY to prevent apps from breaking during the migration process.
Things like supporting both the new keyword-based-constructors AND the old "magic coincidental naming" based constructors.
And funny enough... if you wait to upgrade your PHP4 apps until 5.3 is realsed (it's in Alpha right now), you might not have very many problems at all. Namespaces are finally introduced in 5.3 and one would think that platform libraries will be in their own namespace, preventing the collisions I mentioned earlier.
i just left a meeting and was in need of punching a proverbial wall.
i apologize. you were the wall.
Dear anonymous cowerd,
John McCain supports cloud computing because he feels a strong environment is necessary to the security of the United States.
Only with could computing can we finally break the grip of foreign oil. In the post-9/11 world, energy security is economic security.
John McCain is a true American Hero. I hope you'll support John McCain as much as John McCain supports cloud computing .
The people should be allowed to choose their punishment.
I say we vote on it!
One of my fave's was the fliers in 2004 in inner-city neighborhoods that said things like:
"Remember, to be eligible to vote your Rent and Utility Bills must be paid"
And this is why the 50 State Strategy that Howard Dean has advocated as the Chairman of the Democratic Party is important.
And it's a brilliant stroke of luck for Democrats that we have a candidate with the desire, funding and appeal to implement Dean's strategy.
We NEED to run everywhere. We NEED to have a deep bench. We NEED Democrats running city halls and city councils, we NEED Democrats in county and state level government.
We need a deep bench and we need to have at least as much control over redistricting, election law, ballot access, etc, as the GOP.
While that seems obvious, it's really not possible. Not only is it really f'in expensive to hold an election in a state as large as Florida, it's also in the US constitution that all states will vote for the President on the same day.
Also, in 2000, it wasn't as clean cut as "well, let's stop playing the game now and whoever's in front, wins."
There's only about 100 days between the election and the inauguration. Electors had to cast votes and those votes had to be certified by the congress. And a deadline, the law of the land, was approaching. Above all, peaceful transition of power is the most important thing.
The Florida Supreme Court and the US Supreme Court both granted "victories" to the Democrats, allowing counties to perform recounts.
The real injustice was on the ground, not in the courtroom.
Since there was a deadline, and the process of hand recounts allowed either party to object to the disposition of any given ballot, all the GOP operatives had to do was object to every vote that was determined to be a Gore vote.
This slowed things down so much that there simply was no way to perform a recount in the time given.
I'm sure this strategy wasn't harmed by the fact that George Bush's brother was the Governor of Florida at the time and the GOP secretary of state was a party hack.
All in all, though, well said. Good post.
"I'm sure"
And since you said that, I'm sure you're not qualified to talk about security exploits.
You have no evidence. Just assumption. Yet, you're "sure."
Sounds a lot like a religious zealot, actually.
1. The browser is not built on the .Net platform.
2. The person who wrote that sentence doesn't really understand the way .Net deals with unmanaged code.
3. There is no way for anything to "load DLLs into" anything else.
If you RTFA you'd see that the so-called attacker claims this is "far reaching" and affects more than Microsoft.
The "Shatter Attack" was just an exploit of the inter-process message queue.
And to answer the guy above me, yes, the flaw is fixed in Vista, and there's also a trip-wire to detect this behavior in the event that another flaw is found.
I think that's the GP's point. Vista's IE settings are "correctly configured" "out-of-the-box."
I know, I know, you have some story about how Vista totally sucks and it's personally responsible for killing 300 people in march, 1968 in the Mekong Delta....
But, as a professional software developer, I think Vista security is actually quite good. It's easy to blast UAC if you don't care about or understand the social-engineering behind it.
Exactly. It's saber rattling. Sounds like nothing more.
Furthermore, I love how silly some people here can be. The article says:
But somehow this is a Vista security issue?
Please. Many here on this site, and many articles posted here, have a bias. There's nothing wrong with that, most things in life have a bias in some way.
But there's a difference between "bias" and "intellectual dishonesty."
This is the latter.
This is the silliest thing.
Look, I can do it, too:
I won't buy a Dodge Challenger, so they'll stop making them.
After all, most people didn't buy, oh, an Edsel. And the plan worked, Edsel's went away.
Now, if you have something interesting to say, then say it. But SD TV's are making up a shaply-decreasing share of TV Sales.
Most tube tv's will last, what, 10 years? They will be phased out slowly.
As people own HD TV's, they're going to want content that offers them the full experience they've ALREADY PAID FOR.
I'm a programmer, but in school I majored in Economics.
This is the concept of "sunk cost."
Most people value money they've already spent more than money they may spend. Often past the point of logic.
For example: "I bought an iPhone, so I should subscribe to EDGE"
My personal interpretation of this common behavior is that people want to buy things anyway, so they want justification to do so.
But also, people look at what they buy as an investment, even if it really ISN'T an investment.
I think you have your logic exactly backwards.
It doesn't matter what Blu Ray offers. That's my whole point in my OP.
That's the reason this study is ass backwards.
A Blu Ray player does not drive your TV purchase. Your HD TV drives your Blu Ray purchase.
If you have an HDTV, even a semi-HD 720P set, you're going to want to get your money out of it.
The fact that your TV does not "fully exercise" the Blu Ray player is moot.
Because the Blu Ray player will "fully exercise" the capabilities of your 720p TV.
As a matter of fact, I have a 720p Toshiba in my bedroom and a 1080p Samsung in my living room. I've watched Blu Ray on both.
No doubt, it looks better on 1080, but that's also perhaps the 120hz refresh rate.
But Blu Ray looks FAR BETTER on my 720 set than ANYTHING ELSE.
Better than the HD channels on my Cable (And I have a very good local cable company with a high-bandwidth system that doesn't over-compress HD channels like Comcast does).
Better than the OTA HD.
WAY better than up-converted SD DVD.
Look.. the crux of this argument is you saying that, on balance, consumers will do X.
The crux of MY argument is just logical and anecdotal:
1. Logically, this study is meaningless and ergo any inferences drawn are meaningless. Blu Ray is a HORRIBLE proposition for somebody who currently has a SD TV with no immediate plans to upgrade.
Nobody is going to buy a new TV just to get a new DVD technology. But once you have that TV that you dropped $$ on, you want to get the max out of it.
2. Anecdotally, everyone I know that has an HDTV has or wants to buy a Blu Ray player (Or, previously, some surely wanted HD-DVD).
Honestly, this is bogus.
I bought a 40" Samsung a few months ago that's 1080p, it was "last years model" when I bought it.
My dad has a 32" Sharp that's 1080p. He bought it over 2 years ago.
Furthermore, Blu Ray will still deliver a much better picture on 720p than will an up-converted DVD.
And finally, depending on how you interpret the standard, 720 isn't actually HD.
Do you have a Blu Ray player?
I have owned one since March. I have rented dozens of Blu Ray's thru Netflix in that time.
The vast majority of them begin playing the movie as soon as you put the disc in. Same for those that I've actually purchased.
This is actually a huge improvement upon standard DVD.
But it doesn't MATTER what your plans are.
It would be like saying "I have no plans on buying a Stereo TV" or "I have no plans on buying a Color TV"
Eventually those 2 technologies became so ubiquitous that it doesn't matter that you may not care about them.
Sure, you can by mono and/or B&W TV's, but not if you want a TV of any normal size for a living room.
SD TVs will slowly fade out. And like most technologies, there will be a point where an SD TV costs MORE than an HD TV. Just like you can often get a DVD player now for less than VHS.
It's just about mass production.
And when you have an HD TV, well, you strangely want to make the most of your technology. BluRay is natural for HDTV Owners.
And that's why this study is silly. OF COURSE people are not receptive to an off-the-cuff $1500 purchase of a Blu Ray and the HDTV necessary to make proper use of it.
That's not necessarily true.
The actual cost of the warranty repairs could end up breaking-even for Apple. In which case, they'd be making profit from pooling together everyones warranty money and earning 3-10% annually on it. Especially during the first couple years when things are likely not failing.
If they did this and earned an average of, say, 7% annually, and they compound the interest, they'd make about $40 per warranty over the first 3 years.
And I think it's safe to say that as an Apple customer, if you didn't plunk down $170 on that warranty, chances are you're not going to invest that money in your IRA instead.
I'm not trying to be a "know it all" about this, and I have no idea if Apple is actually doing this. But this is how insurance companies work, and all a warranty is, is an insurance policy. So it makes sense to me.
This is actually under-reported.
I would bet that a majority of men are watching porn, right now .
How do I know this? ...Let's just say that I've been repairing a lot of PCs lately.
yes?
One more thing: Whenever you see a plant close, you see regular folks on the local News, talking about how they're devestated to lose the job that paid them, oh, $27/hr plus OT for screwing in a bolt 900 times per shift.
They always say the same thing: "I just don't think I'll be able to make this much money anywhere else."
Here's a clue: If nobody else will pay you your existing wage for your existing skills, that means you are being overpaid.