Php vs others!

[pmav99]

Όπως σωστά ειπώθηκε, το Ruby On Rails είναι web Framework το οποίο χρησιμοποιείται αρκετά ιδιώς στη Β. Αμερική. Στην Ευρώπη δεν είμαι τόσο σίγουρος οτι είναι τόσο διαδεδομένη η χρήση του (αλλά μπορεί να κάνω και λάθος).

[Kercyn]

Γιατί θεωρείς οτι είναι καλύτερο να έχεις εναν operator με διπλή λειτουργία(addition, concatenation) και όχι διαφορετικούς operator για αριθμητική πράξη και concatenation. Δεν είναι η μόνη γλώσσα η PHP στην οποία ισχύει αυτό.

 

Διαφωνώ με αυτό. Εφ' όσον έχεις ένα συγκεκριμένο τύπο, τότε πράξεις πάνω σε αυτόν θα πρέπει να σου δίνουν αποτέλεσμα τον ίδιο τύπο. Δηλαδή αν έχω "123abc" + "456def", περιμένω "123abc456def" κι όχι 579. Όταν λες "διαφορετικούς operators" τι εννοείς; Μεθόδους τύπου strconcat;

[Aztec]

Διαφωνώ με αυτό. Εφ' όσον έχεις ένα συγκεκριμένο τύπο, τότε πράξεις πάνω σε αυτόν θα πρέπει να σου δίνουν αποτέλεσμα τον ίδιο τύπο. Δηλαδή αν έχω "123abc" + "456def", περιμένω "123abc456def" κι όχι 579. Όταν λες "διαφορετικούς operators" τι εννοείς; Μεθόδους τύπου strconcat;

 

όταν περιμένεις να κάνεις "123abc" +  "456bbb" και εφόσον θέλεις concat  κάνεις "123abc"."245bbb"  

και δεν προσθέτεις αλφαριθμητικά με την χρήση του +

 

η php έχει ας πούμε τον + και .

η pl/sql ας πούμε έχει + και || 

[Kercyn]

Άρα εφ' όσον υπάρχει η τελεία για το concat τότε το + δεν έχει νόημα και θα έπρεπε να χτυπάει. Βέβαια δεν έχω ασχοληθεί αρκετά με PHP για να ξέρω το error handling κλπ, απλώς μου φαίνεται περίεργο το ότι δίνω 2 strings με + και παίρνω έναν αριθμό.

[defacer]

Όχι, είμαστε στην περίπτωση που δεν μπορώ να φανταστώ που θα χρειαζόταν να κάνω τέτοιες ακροβασίες. Και αν τις έκανα, το να πάρω πίσω ένα E_STRICT θα ήταν fair enough, και αξιοπρεπής προειδοποίηση από την πλευρά της γλώσσας ("Ρε σύ, καλά, να στο εκτελέσω, οκ, αν επιμένεις, αλλα... εχμ.... μήπως κάνεις μ@λ@κί@???")

Ακροβασίες το να πάρεις το πρώτο στοιχείο ενός πίνακα που δεν είναι αποθηκευμένος σε μεταβλητή; Και υπάρχουν φυσικά πολλά τέτοια παραδείγματα: έδωσα κι άλλο με το να δώσεις π.χ. null argument by reference, έκανα link και σε απαντήσεις στο StackOverflow όπου γίνονται άλλα κουλά όπως αυτό. Στην τελική γράφω PHP πάνω από 10 χρόνια κι έχουν δει πολλά τα μάτια μου, πράγματα που αν στα πω χωρίς να τα δεις να τρέχουν θα νομίζεις ότι σε δουλεύω. Αν θες να τα πεις όλα αυτά ακροβασίες, no problem αλλά δε συμφωνούμε.

 

Το E_STRICT στην προκειμένη δεν είναι ούτε αξιοπρεπές (γιατί δεν υπάρχει τεχνικός λόγος να μη δουλεύει σωστά, υπάρχει μόνο PHP λόγος) ούτε "fair enough" γιατί όπως είπα ήδη αν θες να έχεις εμπιστοσύνη στον κώδικά σου μιλάμε αποκλειστικά για zero warnings. Και πάλι, αν διαφωνείς no problem.

 

Δηλαδή δεν πρόκειται να δουλέψουμε μαζί;;; Ε δεν πειράζει, θα πιω και θα ξεχάσω... :-D

Πάντως, δεν αντέχω να μην το πω, το αμέσως επόμενο βήμα είναι να γράφεις κώδικα με ένα προφυλακτικό σε κάθε δάχτυλο. Δεν συμφέρει...

Πιο πιθανό το θεωρώ να αλλάξεις άποψη στο μέλλον. Απο κει και πέρα δε νομίζω ότι χρειάζεται να πιείς για να ξεχάσεις, και συ έχεις δουλειά και γω έχω άτομα να δουλέψω μαζί τους, λυπάμαι απλά που η απάντησή σου στο "αυτό είναι πρόβλημα νοοτροπίας" είναι "στα απαυτά μου". Μπορείς να γράψεις ο,τι σου αρέσει στα απαυτά σου, αλλά το πρόβλημα νοοτροπίας δε θα λυθεί έτσι.

 

 

 

Στην περίπτωσή μου για να μπορώ να υπερκαλύψω τις απαιτήσεις της δουλειάς που κάνω (και που θέλω να κάνω) έχω zero tolerance πολιτικές όπως αυτή. Αν εκτός από zero tolerance χρειαζόταν και προφυλακτικό στο δάχτυλο, θα έβαζα προφυλακτικό στο δάχτυλο. Αυτό που λες το διαβάζω ως "έλα μωρέ τι έγινε που άναψα ένα τσιγαράκι στο χώρο του διυλιστηρίου, οι δεξαμενές είναι 100 μέτρα παραπέρα". Για σένα μπορεί να μην έγινε αλλά αν σε έβλεπε ο αξιωματικός ασφαλείας θα ήταν όχι απλά υποχρεωμένος αλλά και καλή ιδέα να σε παραπέμψει γι' αυτό που έκανες, κι αν συνέχιζες να το κάνεις σίγουρα δε θα έμενες εκεί για πολύ.

 

 

 

Να στο φτιάξω;

$a=get_my_array();
echo reset($a);

Fixed.

 

Βλέπεις το δέντρο και χάνεις το δάσος.

 

Θα το πω για πολλοστή φορά: κι εγώ αυτό θα έκανα (και κάνω) σ' αυτή τη θέση, και θα γίνει η δουλειά και θα πάμε σπίτι μας και όλα θα είναι ωραία στον κόσμο και θα έχουμε βγάλει τα λεφτά μας με την αξία μας γιατί φτιάξαμε κάτι "καλό" από κάτι "λιγότερο καλό". Το γεγονός ότι ο μάστορας μπορεί να πάρει μια μπογιά που είναι για το πέος και να σου κάνει μ' αυτήν εξαιρετικό βάψιμο όπως αυτός ξέρει δε σημαίνει πως η μπογιά δεν είναι για το πέος.

 

Bonus: Τώρα μπορείς να χρησιμοποιήσεις το $a παρακάτω, ενώ πριν το αποτέλεσμα της συνάρτησης θα χανόταν, και δεν καταλαβαίνω (ούτε η php!) γιατί θα ήθελες να κάνεις reset ένα array αμέσως πριν "χαθεί"... Δεν έχει δίκιο η κακομοίρα που σου γκρινιάζει;

Είναι θέμα λογικής.

Συνεχίζεις να προσπαθείς να δικαιολογήσεις τα αδικαιολόγητα λόγω έλλειψης γνώσεων.

 

Πρώτον, εγώ δεν "θέλω" να μου κάνει reset η PHP ένα array. Θέλω να πάρω το πρώτο στοιχείο, και η reset() είναι αυτή που κάνει τη δουλειά που θέλω.

 

Δεύτερον, το πρόβλημα αν θες να το δεις ακαδημαϊκά είναι πως η reset() παραβιάζει το SRP. Όταν παραβιάζεις το SRP τότε γίνονται πράγματα όπως αυτό, όπου για τη δική μου χρήση το να κάνω reset ένα array "αμέσως πριν χαθεί" (ανακριβές -- ποιός σου λέει ότι χάθηκε? απαγορεύεται να κρύψω τη μεταβλητή πίσω από μια συνάρτηση για λόγους abstraction?) είναι κάτι παραπάνω απο μια χαρά. Δεν έχει λοιπόν κανένα δίκιο η κακομοίρα.

 

Τρίτον, θέλεις να κάνουμε την ίδια κουβέντα για την current?

 

The current() function simply returns the value of the array element that's currently being pointed to by the internal pointer. It does not move the pointer in any way. If the internal pointer points beyond the end of the elements list or the array is empty, current() returns FALSE.

 

Παρόλο που "it does not move the pointer", θέλει κι αυτή να πάρει το όρισμα by reference (λόγω τεχνικών προβλημάτων PHP) και αυτό με τη σειρά του σε αποτρέπει από το να περάσεις ένα non-variable (λόγω άλλων τεχνικών προβλημάτων).

 

Εδώ τι έχεις να πεις;

 

Και τέλος, το bonus δεν είναι bonus αλλά malus: αν θέλω να χρησιμοποιήσω το $a παρακάτω μπορώ να το βάλω σε μια μεταβλητή και μόνος μου. Αν πάλι δε θέλω, τότε πληκτρολογώ περισσότερο και βάζω μεταβλητές στο scope χωρίς κανένα λόγο.

 

Ε όχι, αυτό είναι το λάθος που δεν πρόκειται να κάνω.

 

Αν θεωρείς ότι η μεταφορά άρτιων γενικών πρακτικών software development από ένα περιβάλλον σ' ένα άλλο είναι λάθος δεν έχω να πω τίποτα περισσότερο.

 

Μήπως διυλίζουμε τον κώνωπα;

Ναι. Έχω δώσει κι άλλα παραδείγματα πέραν της reset() και δε νομίζω πως χρειάζεται να δώσω άλλα.

 

Στην τελική αφού δε διαβάζεις κάποιο πρόβλημα ούτε στο γεγονός ότι συνέχεια (σε κάθε release κυριολεκτικά) βλέπεις πως "φτιάξαμε μερικά segmentation faults"...

 

Γιατί θεωρείς οτι είναι καλύτερο να έχεις εναν operator με διπλή λειτουργία(addition, concatenation) και όχι διαφορετικούς operator για αριθμητική πράξη και concatenation. Δεν είναι η μόνη γλώσσα η PHP στην οποία ισχύει αυτό.

Δε θεωρώ ότι είναι απαραίτητα καλύτερο. Απλά σε συνδυασμό με τους κανόνες του type juggling της PHP (που όσον αφορά τα strings είναι πραγματικά άθλιοι) δημιουργεί πρόβλημα.

[Aztec]

Άρα εφ' όσον υπάρχει η τελεία για το concat τότε το + δεν έχει νόημα και θα έπρεπε να χτυπάει. Βέβαια δεν έχω ασχοληθεί αρκετά με PHP για να ξέρω το error handling κλπ, απλώς μου φαίνεται περίεργο το ότι δίνω 2 strings με + και παίρνω έναν αριθμό.

 

Το + λέει ουσιαστικά προσπάθησε να κάνεις convert το αλφαριθμητικό σε αριθμό για να μπορέσω να κάνω την πρόσθεση. Απλά αντι να το κάνεις εσύ manually όπως λες στο προηγούμενο μήνυμα ώστε να έχει ίδιους τύπους το κάνει αυτόματα. Βολεύει κάποιες φορές

 

Η php είναι λίγο περίεργη και θέλει προσοχή . Δηλαδή στην pl/sql αν δεν μπορέσει να μεταφράσει το αλφαριθμητικό σε αριθμο θα σκάσει . Δηλαδή 

select '100.1'+50  from dual 

αυτο γυρνάει 150.1

select '100BB'+50  from dual 

αυτο θα σκάσει γιατι το 100BB δεν είναι valid αριθμός

 

για να δουμε PHP

$tmp1="10.10";
$tmp2="10B10";
echo $tmp1+$tmp2;

είναι λίγο weird αλλά ο τρόπος λειτουργίας εξηγείται εδω 

Επεξ/σία 24 Απριλίου 2014 από Aztec

[defacer]

Βολεύει κάποιες φορές

 

Πραγματικά δεν ξέρω αν υπάρχει ποτέ περίπτωση να βολεύει.

 

Αν το string προέρχεται από το χρήστη τότε σε ρεαλιστική εφαρμογή θα πρέπει να υπάρχει κάποιο validation ότι όντως σου έχει γράψει νούμερο, οπότε απο κει και πέρα ξέρεις ήδη το επιτρεπόμενο format/range/locale και φυσικά θα χρησιμοποιήσεις τους ανάλογους κανόνες για conversion και όχι το built-in της PHP.

 

Αν δεν προέρχεται από το χρήστη τότε υπάρχουν δύο περιπτώσεις:

• είτε (most likely) έχεις κάποιο λάθος στον κώδικα ή στην είσοδο ή κάπου, οπότε προτιμότερο θα ήταν να φας error για να το καταλάβεις παρά να φέρουν τα d9 όλα άσσους.
• είτε το κάνεις επίτηδες (το ξέρατε αυτό? lolage), οπότε για να ικανοποιήσουμε το βίτσιο σου και για να μη χρειαστεί να γράψεις μια function παραπάνω θα πρέπει όλοι οι mainstream χρήστες να ζήσουν υπο το καθεστώς ότι "12e1" + 1 == 121 (αυτό κι αν είναι lolage).

[geomagas]

Ακροβασίες το να πάρεις το πρώτο στοιχείο ενός πίνακα που δεν είναι αποθηκευμένος σε μεταβλητή;

Όχι, ακροβασίες είναι να προσπαθείς να το κάνεις με τη reset(). Δες παρακάτω.

 

Και υπάρχουν φυσικά πολλά τέτοια παραδείγματα: έδωσα κι άλλο με το να δώσεις π.χ. null argument by reference,

Σου απάντησα σε αυτό.

Για τα υπόλοιπα, συμπεριλαμβανομένων των αποριών του κάθε άσχετου στο SO, που λύνονται με 30'' googling max, νομίζω ότι καταλαβαίνεις τους λόγους που δεν καταδέχομαι να ασχοληθώ.

 

Πιο πιθανό το θεωρώ να αλλάξεις άποψη στο μέλλον. Απο κει και πέρα δε νομίζω ότι χρειάζεται να πιείς για να ξεχάσεις, και συ έχεις δουλειά και γω έχω άτομα να δουλέψω μαζί τους, λυπάμαι απλά που η απάντησή σου στο "αυτό είναι πρόβλημα νοοτροπίας" είναι "στα απαυτά μου". Μπορείς να γράψεις ο,τι σου αρέσει στα απαυτά σου, αλλά το πρόβλημα νοοτροπίας δε θα λυθεί έτσι.

Δεν είπα ποτέ κάτι τέτοιο, μην τα διαστρεβλώνεις. Αν κάποιος αμφισβητεί την υπεργενίκευσή σου και σου ζητά αποδείξεις για αυτό που ισχυρίζεσαι, δεν είναι πρόβλημα νοοτροπίας. Ούτε απαραίτητα άγνοιας, αλλά προσπαθώ να μην ανοίξω τέτοιο θέμα...

 

Βλέπεις το δέντρο και χάνεις το δάσος.

Πλάκα μου κάνεις; Τόση ώρα μου δείχνεις το δέντρο και τώρα πρέπει να δω το δάσος;

 

Θα το πω για πολλοστή φορά: κι εγώ αυτό θα έκανα (και κάνω) σ' αυτή τη θέση, και θα γίνει η δουλειά και θα πάμε σπίτι μας και όλα θα είναι ωραία στον κόσμο και θα έχουμε βγάλει τα λεφτά μας με την αξία μας γιατί φτιάξαμε κάτι "καλό" από κάτι "λιγότερο καλό". Το γεγονός ότι ο μάστορας μπορεί να πάρει μια μπογιά που είναι για το πέος και να σου κάνει μ' αυτήν εξαιρετικό βάψιμο όπως αυτός ξέρει δε σημαίνει πως η μπογιά δεν είναι για το πέος.

Αν η μπογιά έγραφε πάνω:

E_STRICT: Ανακατέψτε καλά με 15% νερό αλλιώς μπορεί να έχετε μειωμένα αποτελέσματα

δεν θα κατηγορούσα την μπογιά, ούτε θα απαιτούσα να δουλέψει καλά με 8% νερό και καθόλου ανακάτεμα.

 

Συνεχίζεις να προσπαθείς να δικαιολογήσεις τα αδικαιολόγητα λόγω έλλειψης γνώσεων.

 

Πρώτον, εγώ δεν "θέλω" να μου κάνει reset η PHP ένα array. Θέλω να πάρω το πρώτο στοιχείο, και η reset() είναι αυτή που κάνει τη δουλειά που θέλω.

Όχι δεν είναι. Αν με ρωτούσες "πως γίνεται", εντελώς μηχανικά θα σου απαντούσα έτσι:

echo array_values(get_my_array())[0];

Τώρα εσύ θέλεις σώνει και καλά να το κάνεις με τη reset(). Και επειδή η php δεν σου κάνει το χατίρι, είναι για πέταμα.

Η αποστολή της reset() είναι άλλη. Θα τη χρησιμοποιούσα μόνο αν με ενδιέφερε να μηδενίσω τον εσωτερικό δείκτη για να τον χρησιμοποιήσω αργότερα. Παρόλα αυτά, "τυγχάνει" να επιστρέφει το πρώτο στοιχείο του πίνακα, και αυτό σε βάζει στη διαδικασία να σκέφτεσαι τέτοιες ακροβασίες (επιμένω).

Αν έφτιαχνα τη reset() προσωπικά θα επέστρεφα boolean, αν χρειαζόταν να επιστρέψω κάτι. Αν μου έλεγες ότι η τιμή που επιστρέφει είναι σχεδιαστικό ατόπημα, θα ήμουν μαζί σου δύο σελίδες τώρα.

 

Δεύτερον, το πρόβλημα αν θες να το δεις ακαδημαϊκά είναι πως η reset() παραβιάζει το SRP. Όταν παραβιάζεις το SRP τότε γίνονται πράγματα όπως αυτό, όπου για τη δική μου χρήση το να κάνω reset ένα array "αμέσως πριν χαθεί" (ανακριβές -- ποιός σου λέει ότι χάθηκε? απαγορεύεται να κρύψω τη μεταβλητή πίσω από μια συνάρτηση για λόγους abstraction?) είναι κάτι παραπάνω απο μια χαρά. Δεν έχει λοιπόν κανένα δίκιο η κακομοίρα.

Δεν το βλέπω ακαδημαϊκά, οπότε...

 

Τρίτον, θέλεις να κάνουμε την ίδια κουβέντα για την current?

 

 

Παρόλο που "it does not move the pointer", θέλει κι αυτή να πάρει το όρισμα by reference (λόγω τεχνικών προβλημάτων PHP) και αυτό με τη σειρά του σε αποτρέπει από το να περάσεις ένα non-variable (λόγω άλλων τεχνικών προβλημάτων).

 

Εδώ τι έχεις να πεις;

Ότι, για να το κάνει έτσι, θα έχει τους λόγους της. Δεν το ψάχνω.

Το λέει το manual; Μαθαίνω τον κανόνα, ξέρω τη συμπεριφορά, πάμε παρακάτω, case closed. Τα λοιπά είναι απλά κουτσομπολιό.

 

Και τέλος, το bonus δεν είναι bonus αλλά malus: αν θέλω να χρησιμοποιήσω το $a παρακάτω μπορώ να το βάλω σε μια μεταβλητή και μόνος μου. Αν πάλι δε θέλω, τότε πληκτρολογώ περισσότερο και βάζω μεταβλητές στο scope χωρίς κανένα λόγο.

Ε και τι φοβάσαι; Μη φθείρεις τα προφυλακτικά;;; :-D

[defacer]

Όχι δεν είναι. Αν με ρωτούσες "πως γίνεται", εντελώς μηχανικά θα σου απαντούσα έτσι:

echo array_values(get_my_array())[0];

Κι αν ήμασταν σε interview θα σε ρωτούσα πρώτα "υπάρχει κάποιο ενδεχόμενο μειονέκτημα σ' αυτό τον τρόπο;" και στη συνέχεια "η array_values πώς ακριβώς πιστεύεις ότι λειτουργεί" και άλλα σ' αυτό το στυλ μέχρι είτε να καταλάβεις πως αυτό είναι απαγορευτικά wasteful για κώδικα γενικής χρήσης (αν ο πίνακας έχει 1M στοιχεία?) και άρα ανεπίτρεπτο, είτε να πειστώ πως δεν το 'χεις και να περάσω στον επόμενο.

 

By the way, θα εκδηλωθώ και θα πω ότι αυτό που έγραψες προέρχεται κατευθείαν από googling μιας και εσύ νωρίτερα όπως φάνηκε χρησιμοποιείς 5.3 στην οποία αυτό δε θα δουλέψει (lol) επειδή δεν υποστηρίζεται array dereferencing.

 

Τώρα εσύ θέλεις σώνει και καλά να το κάνεις με τη reset(). Και επειδή η php δεν σου κάνει το χατίρι, είναι για πέταμα.

 

See above. Θέλω να το κάνω με τη reset() επειδή δεν υπάρχει άλλος τρόπος που να γίνεται σε O(1) χρόνο και μνήμη και που να μην είναι statement αλλά expression.

 

Και δεν είμαι ο μόνος.

 

Ότι, για να το κάνει έτσι, θα έχει τους λόγους της. Δεν το ψάχνω.

Το λέει το manual; Μαθαίνω τον κανόνα, ξέρω τη συμπεριφορά, πάμε παρακάτω, case closed. Τα λοιπά είναι απλά κουτσομπολιό.

Αν θέλεις να φτάσεις στα υψηλότερα επίπεδα κάποιας τέχνης είναι απαραίτητο πρώτον να μη βλέπεις τα εργαλεία σου σα μαύρο κουτί αλλά να ξέρεις πώς δουλεύουν με κάθε λεπτομέρεια και δεύτερον να ψάχνεις τα πάντα, ακόμα κι αν φαίνεται πως κάποιος είχε τους λόγους του.

 

Και μιλώντας εκ πείρας, όταν έχεις να κάνεις με ανθρώπους πολύ συχνά ο λόγος ήταν πως τα έξυνε ή πως δεν τον ενδιέφερε.

Δεν είπα ποτέ κάτι τέτοιο, μην τα διαστρεβλώνεις. Αν κάποιος αμφισβητεί την υπεργενίκευσή σου και σου ζητά αποδείξεις για αυτό που ισχυρίζεσαι, δεν είναι πρόβλημα νοοτροπίας.

 

Πρόβλημα νοοτροπίας φυσικά δεν είναι το να ζητάς αποδείξεις. Είναι όμως το να γράφεις κώδικα που δίνει warnings και να μη σου καίγεται καρφί.

[Aztec]

 

Πραγματικά δεν ξέρω αν υπάρχει ποτέ περίπτωση να βολεύει.

 

Αν το string προέρχεται από το χρήστη τότε σε ρεαλιστική εφαρμογή θα πρέπει να υπάρχει κάποιο validation ότι όντως σου έχει γράψει νούμερο, οπότε απο κει και πέρα ξέρεις ήδη το επιτρεπόμενο format/range/locale και φυσικά θα χρησιμοποιήσεις τους ανάλογους κανόνες για conversion και όχι το built-in της PHP.

 

Αν δεν προέρχεται από το χρήστη τότε υπάρχουν δύο περιπτώσεις:

• είτε (most likely) έχεις κάποιο λάθος στον κώδικα ή στην είσοδο ή κάπου, οπότε προτιμότερο θα ήταν να φας error για να το καταλάβεις παρά να φέρουν τα d9 όλα άσσους.
• είτε το κάνεις επίτηδες (το ξέρατε αυτό? lolage), οπότε για να ικανοποιήσουμε το βίτσιο σου και για να μη χρειαστεί να γράψεις μια function παραπάνω θα πρέπει όλοι οι mainstream χρήστες να ζήσουν υπο το καθεστώς ότι "12e1" + 1 == 121 (αυτό κι αν είναι lolage).

 

 

είναι επιλογή της PHP να κάνει simulate την strtod. 

 

Απο εκεί και πέρα αν υποθέσω ότι έχω να κάνω πράξεις πολλές πάνω στο string γιατί να μην κάνω validate οτι ειναι αριθμητικό το περιεχόμενο και στην συνέχεια να το σκίσω στα implicit conversions χωρίς να χρειαστεί να κάνω ουτε ενα cast ?

[defacer]

Απο εκεί και πέρα αν υποθέσω ότι έχω να κάνω πράξεις πολλές πάνω στο string γιατί να μην κάνω validate οτι ειναι αριθμητικό το περιεχόμενο και στην συνέχεια να το σκίσω στα implicit conversions χωρίς να χρειαστεί να κάνω ουτε ενα cast ?

1. Γιατί δεν υπάρχει μοναδικός ορισμός του "αριθμητικό" και ακόμα χειρότερα στην πράξη συνήθως δε θέλεις να αντιμετωπίσεις το "1e100" σαν αριθμητικό αλλά σα σφάλμα (πράγμα που παρεμπιπτόντως κάνει την is_numeric... λιγότερο από χρήσιμη).
2. Γιατί αν το αφήσεις στο implicit δεν ξέρεις αν είναι ακέραιος ή όχι, ενώ στην πράξη σχεδόν πάντα σε νοιάζει. Πρώτον για να δώσεις feedback στο χρήστη και δεύτερον γιατί αν αυτό που πήρες είναι σαν integer "μεγαλύτερο" από 53 bits τότε ενδεχομένως (ούτε γι' αυτό δε μπορείς να είσαι σίγουρος αν δεν κοιτάξεις την PHP_INT_SIZE) περνάς σε float και έχεις απώλεια ακρίβειας και αρχίζουν τα παρατράγουδα.

[geomagas]

Κι αν ήμασταν σε interview θα σε ρωτούσα πρώτα "υπάρχει κάποιο ενδεχόμενο μειονέκτημα σ' αυτό τον τρόπο;" και στη συνέχεια "η array_values πώς ακριβώς πιστεύεις ότι λειτουργεί" και άλλα σ' αυτό το στυλ μέχρι είτε να καταλάβεις πως αυτό είναι απαγορευτικά wasteful για κώδικα γενικής χρήσης (αν ο πίνακας έχει 1M στοιχεία?) και άρα ανεπίτρεπτο, είτε να πειστώ πως δεν το 'χεις και να περάσω στον επόμενο.

Δεν πάω σε interviews, εκ πεποιθήσεως. Αλλά για να δούμε... χμμμ....

 

- Θα σου έλεγα ότι, για μία τόσο γενική ερώτηση, θα απαιτούσα να δεχτείς μία τόσο γενική απάντηση σαν σωστή. Αν επιμένεις να μου βάζεις άλλα δεδομένα μετά από την απάντηση μου, πάει να πεί ότι ο ...επόμενος είναι ο μπατζανάκης σου και η δουλειά βρωμάει.

 

- Θα σου έλεγα επίσης ότι, στη γενική περίπτωση αυτός είναι ο τρόπος, τώρα, αν η συγκεκριμένη εφαρμογή έχει άλλες απαιτήσεις, θα πρέπει να το δούμε υπό το συγκεκριμένο πρίσμα. Υπάρχουν κι άλλοι τρόποι (χακεριές), όπως ο reset(f()) όπου, εν ανάγκη, χαλαλίζουμε και ένα E_STRICT βρε αδερφέ! Τώρα, αν το E_STRICT μας χαλάει το φενγκ-σούι, δεν θα λυπηθούμε μερικά keystrokes να το βάλουμε πρώτα σε μία μεταβλητή...

 

- Θα σου έλεγα τέλος ότι, αν εσείς εδώ έχετε αποφασίσει να διαχειρίζεστε 1M records με flat arrays (!) και μετά πρέπει εγώ να βγάλω το φίδι από την τρύπα, τότε έχετε κάνει κάτι θεμελιωδώς λάθος, έχετε καταπιεί την καμήλα και τώρα διυλίζετε τον κώνωπα. Και ότι με αυτή τη λογική, δεν επιθυμώ να δουλέψω στο μπακάλικό σας και λυπάμαι για τα 10' που ξόδεψα στη συνέντευξη-καψόνι.

 

By the way, θα εκδηλωθώ και θα πω ότι αυτό που έγραψες προέρχεται κατευθείαν από googling μιας και εσύ νωρίτερα όπως φάνηκε χρησιμοποιείς 5.3 στην οποία αυτό δε θα δουλέψει (lol) επειδή δεν υποστηρίζεται array dereferencing.

Δεν προέρχεται από googling, ο παπι με ξεστράβωσε.

Αλλά πες μου κάτι, εντάξει είναι μοναχικά εκεί στην κορυφή, αλλά είναι ανάγκη να πατρονάρεις τους άλλους σε τέτοιο πια βαθμό;

Ειλικρινά πιστεύεις ότι δεν θα πήγαινε το μυαλό μου σε κάτι τόσο απλό και έπρεπε να το γκουγκλίσω;

 

See above. Θέλω να το κάνω με τη reset() επειδή δεν υπάρχει άλλος τρόπος που να γίνεται σε O(1) χρόνο και μνήμη και που να μην είναι statement αλλά expression.

Ok, ok! Χαλάω εγώ χατίρι;;;

 

Και δεν είμαι ο μόνος.

Αυτό το γκούγκλισες έτσι; Πες την αλήθεια!

 

Αν θέλεις να φτάσεις στα υψηλότερα επίπεδα κάποιας τέχνης είναι απαραίτητο πρώτον να μη βλέπεις τα εργαλεία σου σα μαύρο κουτί αλλά να ξέρεις πώς δουλεύουν με κάθε λεπτομέρεια και δεύτερον να ψάχνεις τα πάντα, ακόμα κι αν φαίνεται πως κάποιος είχε τους λόγους του.

Λάθος. Αλλά αυτό είναι άποψή μου. Μπορεί να προέρχεται κι από άγνοια...

 

Πρόβλημα νοοτροπίας φυσικά δεν είναι το να ζητάς αποδείξεις. Είναι όμως το να γράφεις κώδικα που δίνει warnings και να μη σου καίγεται καρφί.

Error: Κάτι που είναι ανεπίτρεπτο να συμβαίνει. Πχ τα συντακτικά λάθη στο compilation ("Ντεν καταλαμπαίνει τι με λες...") και τα exceptions στο runtime ("Oops, έκατσε στραβή, πως το αντιμετωπίζουμε;").

Warning: Κάτι που μπορεί να προκαλέσει ατύχημα, και η γλώσσα έχει την υποχρέωση να σε προειδοποιήσει. Αν όμως εσύ ξέρεις τι κάνεις, το παραβλέπεις.

 

Έχει νόημα ο διαχωρισμός. Εκ φύσεως το warning είναι κάτι που υπό συνθήκες μπορείς να το παραβλέψεις.

Αλλιώς, θα τα κάναμε όλα exceptions, για να μπορούμε να τα κάνουμε και catch...

[Aztec]

 

• Γιατί δεν υπάρχει μοναδικός ορισμός του "αριθμητικό" και ακόμα χειρότερα στην πράξη συνήθως δε θέλεις να αντιμετωπίσεις το "1e100" σαν αριθμητικό αλλά σα σφάλμα (πράγμα που παρεμπιπτόντως κάνει την is_numeric... λιγότερο από χρήσιμη).
• Γιατί αν το αφήσεις στο implicit δεν ξέρεις αν είναι ακέραιος ή όχι, ενώ στην πράξη σχεδόν πάντα σε νοιάζει. Πρώτον για να δώσεις feedback στο χρήστη και δεύτερον γιατί αν αυτό που πήρες είναι σαν integer "μεγαλύτερο" από 53 bits τότε ενδεχομένως (ούτε γι' αυτό δε μπορείς να είσαι σίγουρος αν δεν κοιτάξεις την PHP_INT_SIZE) περνάς σε float και έχεις απώλεια ακρίβειας και αρχίζουν τα παρατράγουδα.

αν θέλεις να τσεκάρεις ακέραιο παίξε με is_int και όχι με is_numeric . Ο χρηστής δεν θα βαλει τεράστιο αριθμό απλα γιατι δεν θα μπορει να βαλει . Απο και πέρα μια χαρά θα παίξει το implicit . Φυσικά εσύ μην παίξεις . Δεν σου είπε κανεις να παίξει με το ζόρι.

[defacer]

 

Βγαίνουμε πολύ offtopic γιατί καταλήξαμε στα interviews κλπ. Νομίζω δεν έχει νόημα να συνεχίσουμε στο thread, οπότε δίνω ένα σε spoiler κι απο κει και πέρα μαλλον καλύτερα με PM?

 

 

 

Δεν πάω σε interviews, εκ πεποιθήσεως. Αλλά για να δούμε... χμμμ....

?????????

 

- Θα σου έλεγα ότι, για μία τόσο γενική ερώτηση, θα απαιτούσα να δεχτείς μία τόσο γενική απάντηση σαν σωστή. Αν επιμένεις να μου βάζεις άλλα δεδομένα μετά από την απάντηση μου, πάει να πεί ότι ο ...επόμενος είναι ο μπατζανάκης σου και η δουλειά βρωμάει.

Αυτό αν το κάνεις δεν έχεις να κερδίσεις απολύτως τίποτα και με τον τρόπο που το είπα δεν έχεις και κανένα δίκιο. Έχω όχι μόνο δικαίωμα αλλά και υποχρέωση να κάνω ερωτήσεις που θα μου επιτρέψουν να βρω το επίπεδο του interviewee όσο το δυνατόν πιο γρήγορα και με ακρίβεια για να μη χάνω ούτε το δικό μου χρόνο ούτε το δικό του.

 

Ακόμα κι αν σου έλεγα "bazinga! λάθος! ο πίνακας έχει 1M elements" θα έπρεπε να το πάρεις σαν hint πως σου ζητάω όχι μηχανικές απαντήσεις αλλά κριτική σκέψη. Στην τελική ας μην κοροϊδευόμαστε, αν σε ρωτούσα πώς θα κάνεις sort και μου έλεγες bubble sort και επέμενες μέχρι τελικής πτώσεως, θα σε έκοβα και θα είχα απόλυτο δίκιο. Οι ερωτήσεις γίνονται για να δούμε πώς σκέφτεσαι και αν σκέφτεσαι, όχι για να κάτσουμε να μαλώσουμε για technicalities. Ρίξε αν θες μια ματιά στο "the design question" εδώ.

 

Από την άλλη βέβαια αν μετά από αυτή την απάντηση σου έλεγα στεγνά "λάθος, μηδέν πόντοι, πάμε παρακάτω" τότε φυσικά θα ήμουν άθλιος interviewer.

 

Επίσης, αν σημαίνει τίποτα για σένα αυτό, στο τελευταίο interview που έκανα συνέβησαν τα εξής:

1. Μου είπε ο interviewer πως σε 2 ερωτήσεις οι απαντήσεις που έδωσα ήταν οι πιο λεπτομερείς και αναλυτικές που έχουν δει ως τώρα.
2. Το 90% των απαντήσεων αυτών ήταν προτάσεις της μορφής "αν τυχόν συμβεί αυτό τότε θα υπάρχει εκείνο το πρόβλημα".

Θα μπορούσα αντί να γίνω αναλυτικός να μη πω τίποτα και αν με τσιγκλούσαν π.χ. "κι αν ο αριθμός είναι αρνητικός" να απαντάω "ε δε μου είπες πως είναι αρνητικός". Αλλά δε μου αρέσει να σαμποτάρω τον εαυτό μου επίτηδες.

 

- Θα σου έλεγα επίσης ότι, στη γενική περίπτωση αυτός είναι ο τρόπος, τώρα, αν η συγκεκριμένη εφαρμογή έχει άλλες απαιτήσεις, θα πρέπει να το δούμε υπό το συγκεκριμένο πρίσμα. Υπάρχουν κι άλλοι τρόποι (χακεριές), όπως ο reset(f()) όπου, εν ανάγκη, χαλαλίζουμε και ένα E_STRICT βρε αδερφέ! Τώρα, αν το E_STRICT μας χαλάει το φενγκ-σούι, δεν θα λυπηθούμε μερικά keystrokes να το βάλουμε πρώτα σε μία μεταβλητή...

 

"Στη γενική περίπτωση αυτός είναι ο τρόπος"; Τι πάει να πει αυτό; Οι προσεγγίσεις με reset(), με list() κλπ τι είναι, ειδικές περιπτώσεις;

 

- Θα σου έλεγα τέλος ότι, αν εσείς εδώ έχετε αποφασίσει να διαχειρίζεστε 1M records με flat arrays (!) και μετά πρέπει εγώ να βγάλω το φίδι από την τρύπα, τότε έχετε κάνει κάτι θεμελιωδώς λάθος, έχετε καταπιεί την καμήλα και τώρα διυλίζετε τον κώνωπα. Και ότι με αυτή τη λογική, δεν επιθυμώ να δουλέψω στο μπακάλικό σας και λυπάμαι για τα 10' που ξόδεψα στη συνέντευξη-καψόνι.

Αν το έλεγες μ' αυτό το attitude θα έφευγες αμέσως μετά επειδή:

1. Θα είχες επιλέξει αντί να κάνεις μια ουσιαστική κριτική απλά να γίνεις εξυπνάκιας. Όταν ρωτάσαι πώς παίρνεις το πρώτο στοιχείο ενός πίνακα, αν αισθάνεσαι ότι χρειάζεσαι περισσότερα δεδομένα είναι υποχρέωσή σου να τα ζητήσεις γιατί δε γράφουμε σχολικό διαγώνισμα, εξετάζουμε το πώς κινείσαι επαγγελματικά σ' ένα μη εργαστηριακό περιβάλλον.
2. Η απάντηση αυτή είναι όχι μόνο εξυπνακίστικη αλλά και κενή νοήματος. Εγώ προσωπικά μπορεί να σου ανταπαντούσα πως όχι, δεν έχουμε στην πράξη 1M records σε flat arrays, αλλά έχουμε 1Κ records που τα επεξεργαζόμαστε σε O(n^2) με loop επειδή τον κώδικα τον έγραψε κάποιος που δε σκέφτεται πέρα από το πρώτο που θα του έρθει στο μυαλό.

 

Δεν προέρχεται από googling, ο παπι με ξεστράβωσε.

 

Άρα λάθος μου.

 

Αλλά πες μου κάτι, εντάξει είναι μοναχικά εκεί στην κορυφή, αλλά είναι ανάγκη να πατρονάρεις τους άλλους σε τέτοιο πια βαθμό;

 

Είναι όντως κάπως μοναχικά εδώ. Δε μπορώ να φανταστώ πώς είναι στην κορυφή, είναι πολύ μακριά.

 

Συγγνώμη που προσπαθώ να σου δώσω να καταλάβεις πράγματα που φανερά δεν έχεις στο μυαλό σου λόγω έλλειψης εμπειρίας με τρόπο που δε σου αρέσει. Σταματάω εδώ γιατί στην τελική ούτε και μένα μ' αρέσει.

 

Ειλικρινά πιστεύεις ότι δεν θα πήγαινε το μυαλό μου σε κάτι τόσο απλό και έπρεπε να το γκουγκλίσω;

 

Όχι. Πίστευα απλώς ότι το γκούγκλισες, τελεία. Το γιατί το γκούγκλισες και το αν πήγε το μυαλό σου μόνο του ή όχι δε με απασχόλησε, και please μη μου βάζεις λόγια στο στόμα. To point που ήθελα να κάνω είναι πως εφόσον το γκούγκλισες (ή το είδες από το παπί, το ίδιο πράγμα για τις ανάγκες της συζήτησης) ξανασκέψου το λίγο πριν έρθεις να το μοστράρεις σαν την υπερτέλεια λύση σε κάποιον που έχει φάει τα χρόνια του στην PHP.

 

 

αν θέλεις να τσεκάρεις ακέραιο παίξε με is_int και όχι με is_numeric . Ο χρηστής δεν θα βαλει τεράστιο αριθμό απλα γιατι δεν θα μπορει να βαλει . Απο και πέρα μια χαρά θα παίξει το implicit . Φυσικά εσύ μην παίξεις . Δεν σου είπε κανεις να παίξει με το ζόρι.

 

Τι εννοείς "δε θα μπορεί να βάλει";      

 

Σοβαρά τώρα μιλάμε για web εφαρμογές και λέμε "τι μπορεί να κάνει ο χρήστης"; Μπορεί να κάνει οτιδήποτε καταφέρει μιλώντας στην εφαρμογή σου με καθαρό HTTP και έχεις την υποχρέωση να προβλέψεις τα πάντα (λέμε τώρα -- επιλογή του καθενός αν την έχει).

 

Η is_int() δε σου λέει απολύτως τίποτα απ' αυτά που θες να μάθεις επειδή μπορεί μια χαρά να έχεις σε float το 2^40 και δεν υπάρχει κανένα πρόβλημα.

[Aztec]

 

Τι εννοείς "δε θα μπορεί να βάλει";      

 

Σοβαρά τώρα μιλάμε για web εφαρμογές και λέμε "τι μπορεί να κάνει ο χρήστης"; Μπορεί να κάνει οτιδήποτε καταφέρει μιλώντας στην εφαρμογή σου με καθαρό HTTP και έχεις την υποχρέωση να προβλέψεις τα πάντα (λέμε τώρα -- επιλογή του καθενός αν την έχει).

 

Η is_int() δε σου λέει απολύτως τίποτα απ' αυτά που θες να μάθεις επειδή μπορεί μια χαρά να έχεις σε float το 2^40 και δεν υπάρχει κανένα πρόβλημα.

 

 

defacer σαν παιδακια κάνουμε. Πάμε πάλι .

 

Ας πούμε ότι έχουμε την απαίτηση να υλοποιήσουμε εναν αλγόριθμο για ταυτότητα μια ξένης χώρας. Πρέπει η ταυτότητα να είναι δεκατρείς αριθμητικοί χαρακτήρες.  ΠΡΙΝ ξεικινήσουμε να κάνουμε validate τον αλγόριθμο και το checksum  δεν πρέπει να κάνουμε έλεγχο οτι πληρούνται οι προυποθέσεις ? ότι δηλαδή ειναι δεκατρείς αριθμητικοι χαρακτηρες ? 

 

ΌΤΑΝ γίνει αυτό ΕΧΩ ΠΡΟΒΛΗΜΑ ΝΑ ΧΡΗΣΙΜΟΠΟΙΗΣΩ implicit convert ?