Comment On Vector Oriented Programming

Alex Papadimoulis:

 * @param getOrSet indicates what action to take. can be:
* "get", "set", "close", "find"

Alex Papadimoulis:

And sure, you may need to constantly
pepper your code with things like, "poNumber =
((orderVector[4]=="shipped")?orderVector[6 ]:orderVector[5 ])", but you
see, that's the beauty of it. Pepper makes everything taste better.

poNumber = ((orderVector.get(4).equals("shipped"))?orderVector.get(6):orderVector.get(5))

That is awesome.

Yes! Finally, void* is back!

Alex Papadimoulis:

And sure, you may need to constantly pepper your code with things like, "poNumber = ((orderVector[4]=="shipped")?orderVector[6 ]:orderVector[5 ])", but you see, that's the beauty of it. Pepper makes everything taste better.

Anonymous:

That is awesome.

object DoEverythingConceivable(string whatToDo, object whatToDoItWith)

ammoQ:

Alex Papadimoulis:

And sure, you may need to constantly
pepper your code with things like, "poNumber =
((orderVector[4]=="shipped")?orderVector[6 ]:orderVector[5 ])", but you
see, that's the beauty of it. Pepper makes everything taste better.

Unless I missed something, it's rather

poNumber = ((orderVector.get(4).equals("shipped"))?orderVector.get(6):orderVector.get(5))

ammoQ:

Well, at least they use Vector. Most "clever" people use hashtables to implement "flexible" objects, but using Vectors instead adds some, well, inflexibility.

Yes. It is not strongly typed but, at least, it is rigidly obtuse!

The developer in me says "you write it, you debug it".

The tester in me says "you write it, you test it".

We have heard of black box testing - this looks like black box code.

- SPT

foxyshadis:

If it's Java, yes; if it's C++ (which I assume given Alex's example) it's all overloaded into normal array & equality syntax.

Except C++ does have a "Vector" or a "String"  (it has "std::string" and "std:vector<Order>".)

loneprogrammer:

Anonymous:

That is awesome.

object DoEverythingConceivable(string whatToDo, object whatToDoItWith)

DoEverythingConceivable("go to hell", handbasket);

I don't think that would ever return.

foxyshadis:

If it's Java, yes; if it's C++ (which I assume given Alex's example)
it's all overloaded into normal array & equality syntax. Ah,
operator overloading, a bottomless fountain of deadly wtfs. =D

Anonymous:

Actually, in Java you need to cast everything coming out of a Vector
(since Vectors store Objects).  So really, it is something like:

poNumber = ((((String)orderVector.get(4)).equals("shipped"))?(String)orderVector.get(6):(String)orderVector.get(5));

Adonoman:

Looks like someone spent too much time using LISP, or Perl, or worse... APL

Alex Papadimoulis:

 * @param  orderNumber     number of the order
 * @param  orderId         id of the order
 * @param  customerNumber  number of the customer

Alex Papadimoulis:

 * @return                 vector of 18 elements or a vector of vectors
 *                         or an error vector

VB 6.0 and earlier used to have (something like) this, it was called "Variant" datatype. Highly prone to runtime errors, and often a PITA to debug. The .NET platform did away with it for good reason....

So the question from those of us not up-to-date on VOP development; is this WTF a crappy implementation of VOP, or is VOP a big WTF to begin with?

-Me

Hubert Farnsworth:

:-P

Adonoman:

Looks like someone spent too much time using LISP, or Perl, or worse... APL

Anonymous:

Actually, in Java you need to cast everything coming out of a Vector
(since Vectors store Objects).  So really, it is something like:

poNumber = ((((String)orderVector.get(4)).equals("shipped"))?(String)orderVector.get(6):(String)orderVector.get(5));

poNumber = ((orderVector.get(4).equals("shipped"))?(String)orderVector.get(6):(String)orderVector.get(5));

But can it return a vector of vectors of vectors?

--Rank

Anonymous:

orderVector.get(4).equals("shipped")  --> will return false 100% of the time.

ammoQ:

Well, it seems nothing can keep the clever guys from using Javadoc comments and Java classnames in C++ program. Why not?

Anonymous:

Casting is required.  Hard-coding "shipped" in the equals() method
creates a new String object on the fly.  Though orderVector.get(4)
may well return a String object who's value may be "shipped", it will
not be the same String object as the one created on the fly.  As
such, the Object equals(Object) call will fail.  In other words:



orderVector.get(4).equals("shipped")  --> will return false 100% of the time.

((String)orderVector.get(4)).equals("shipped") 
--> will return false ONLY if the value in the String returned from
the vector equals the value of the String "shipped".

MVP:

Nope, first cast is needed.  The orderVector.get(4) call returns
an Object, NOT a String.  Polymorphism doesn't apply in this
case.  Java doesn't know it's a String until it is casted. 
Even if that object is technically a String, not casting it will force
Java to call Object's equals() method, not String's equals()
method. 

Anonymous:

So basically, we eschew all sense of strongly typed objects or even run-time binding, such as referencing an object by property name, and end up with Vector Pepper.