Reputation: 6030 Overlord
- Active Posts:
- 13,067 (4.85 per day)
- 16-October 07
- Profile Views:
- Last Active:
- Today, 06:49 PM
- OS Preference:
- Favorite Browser:
- Favorite Processor:
- Who Cares
- Favorite Gaming Platform:
- Your Car:
- Who Cares
- Dream Kudos:
- Expert In:
Posts I've Made
Posted 1 Mar 2015is clearly insulting.
To what, exactly? You? No. PHP? Not exactly. To the idea of OOP in PHP? Sure.
Ideas don't have feelings. They may be insulted without reservation. Ideas should be criticized. Constantly. Because it's only through weathering such assaults that we can judge their merit. Talking issue with the language of criticism, rather than the critique itself, is at best unproductive, at worst deflection.
Posted 1 Mar 2015Some PHP gurus might get mad at me, but I generally find OOP in PHP to be like a fish on a unicycle; rather absurd and sad.
Don't worry, we are used to this elitist attitude from a lot of Java/.NET/C++/etc... developers.
It used to piss me of a bit - and honestly still does when I see it from smart people such as yourself - but at this point it's more amusing than anything.
I could never quite figure out why good developers feel the need to bash another language like this, every chance they get.
Curious. No, I was not bashing PHP. PHP gets bashed enough without me. I like PHP and was expressing my point of view. If you wish to see that as some kind of personal attack, well, that's up to you.
I don't use pointers in C# or goto most places. I never used OOP in perl, either, because it was poorly implement, and I liked perl. I don't write functional code in C or imperative code in F#. The worst design decision I ever made was using custom types in an Oracle database...
Playing to an environment's strengths is not bashing it; it's using your tools to best effect.
Posted 1 Mar 2015If you're using PDO, you using OOP...
Some PHP gurus might get mad at me, but I generally find OOP in PHP to be like a fish on a unicycle; rather absurd and sad.
OOP is for organizing your data. In some instances, like a library (e.g. PDO) it make sense. However, instantiating objects isn't free and those objects only exist for the request and are gone.
PHP has nice associate arrays that would fulfill the role of a messenger class. Each page is essentially an "object." Do you really need type safety when data is ultimately pushed out as text and pulled back as text? Or will each page end up figuring it out, anyway?
While you can use classes for reusable code, but you can use functions for that as well.
Short answer, if you are happy without OOP, then be happy.
Posted 1 Mar 2015Hmm... I don't know squat about "relational calculus," I'm afraid. But where it's sort of applied, SQL, that I've got.
For SQL, you should use JOIN syntax and avoid NOT IN at all costs. Though, your NOT IN seems almost theoretical, as you're not actually applying it to a data point directly. This stuff is a lot easier to understand if you have an actual, real, database you can play with.
1. Your first answer will get all the beers sold in all the bars Joe frequents. It will also get duplicates. So, if only one bar serves Guinness, but others don't, the answer will be incorrect. Your second answer is... confusing.
2. Since your NOT IN here doesn't line up with SQL, but appears to be getting used as a NOT EXIST, I'll say yes.
3 4. I'm looking at this and it bears so little resemblance to real life, I honestly can't say. Sorry.
Right, here's my answer, broken down.
First, all Joe's bars:
SELECT bar FROM Frequents WHERE drinker = 'Joe'
Now, let's get a beer count from that subset:
SELECT s.beer, count(*) as ServedInHowManyOfJoesBars FROM Serves s INNER JOIN Frequents f ON s.bar = f.bar AND f.drinker = 'Joe' GROUP BY s.beer
Now, check the count against the total number of bars:
SELECT s.beer FROM Serves s INNER JOIN Frequents f ON s.bar = f.bar AND f.drinker = 'Joe' GROUP BY s.beer HAVING count(*) = (SELECT count(*) FROM Frequents WHERE drinker = 'Joe')
I'm not sure how useful that was to you, as it's not quite the "relational calculus" bend. However, in the applied world of RDBMS' you could actually use that.
Hope this helps.
Posted 28 Feb 2015Although "print" and "return" are different things, I don't big difference between using them in a function. I mean: you can type print x and function will give you x, you can type return x and you get the same result...
Right, if you have encode() and it asks the user for input prints out the result, fine. Then you have decode, which also asks the user and prints. What if you want to use your encode elsewhere? On some value from somewhere else?
Here is the cycle you've set yourself up for:
call encode function, enter data, see output, copy output somewhere call decode function, go find that output you've copied, type it exactly, see output and figure out if it's working.
Conversely, leaving IO out of your function allows you do to this:
e = encode(text) d = decode(e) print("given:", text) print("encoded:", e) print("decoded:", d) print("works:", (text==d))
For how you're going to decode, you'd reasonably want:
def getKeyFromFile(filename): # your code here def getKeyRandom(keySize): # your code here # this should be what you already have def encode(key, text): # your code here def decode(key, text) # your code here
- Member Title:
- Dreaming Coder
- Age Unknown
- Birthday Unknown
- Jersey, be afraid.
- Years Programming:
- Programming Languages:
Showing 50 random friends of 106 (View all)