@quynh001 Đoạn trên thì cũng không hẳn là type hint, mà chỉ là comment cho kiểu của biến thôi (^^;) nhưng đúng là nên để tên class Illuminate\Foundation\Application ở đây thì hơn =))

Khi viết một package, chắc chắn không nên sử dụng integration services từ package khác mà nên dùng dependencies, ngay cả khi package chỉ phục vụ cho một framework duy nhất. Em nghĩ tốt nhất là như vậy.

Câu này thì anh không hiểu lắm (^^;)

Em tìm hiểu thì thấy lluminate\Contracts\Session\Session thì không có method flash. Flash chỉ có trong concrete mặc định của nó là Illuminate\Session\Store.

Cái này thì đúng là có vấn đề (^^;), một là em không type hint interface nữa, gọi helper của laravel thôi :v Type hint interface thì không nên gọi hàm không có trong interface đó

Mà em thì chọn cách type-hint interface, nó thuận lợi cho việc mở rộng và dễ test hơn.

Anh cũng nghĩ vậy, type hint thì nên là interface

@thangtd90 Typehint chính là vấn đề mà em gặp phải, mà nguồn Laravel đã quá "linh động"

Kì thực, nếu chúng ta chỉ sử dụng concrete mặc định mà không thay đổi thì chẳng có vấn đề gì cả.

• Nhưng đây là constructor của ServiceContainer

/**
 * Create a new service provider instance.
 *
 * @param  \Illuminate\Contracts\Foundation\Application  $app
 * @return void
 */
public function __construct($app)
{
    $this->app = $app;
}

• Laravel đã typehint interface Application nhưng lại sử dụng method từ concrete mặc định của nó. Em không thích cách làm như thế. Đây chỉ là ví đụ nhỏ em thấy. Còn nhiều trường hợp typehint khác mà ông Taylor vẫn chấp nhận điều tương tự. Đó là lý do của tác giả, em chỉ thắc mắc chút thôi.

Cụ thể, vấn đề của em gặp phải như sau:

• Khi viết một package, chắc chắn không nên sử dụng integration services từ package khác mà nên dùng dependencies, ngay cả khi package chỉ phục vụ cho một framework duy nhất. Em nghĩ tốt nhất là như vậy.

• Trong package của mình, em cần sử dụng type-hint Session interface và cần sử dụng method flash.

• Em tìm hiểu thì thấy lluminate\Contracts\Session\Session thì không có method flash. Flash chỉ có trong concrete mặc định của nó là Illuminate\Session\Store.

• Như vậy, hoặc thay vì type-hint interface, em phải type-hint concrete hoặc em cần tự khai báo một interface mới có method flash.

• Mà em thì chọn cách type-hint interface, nó thuận lợi cho việc mở rộng và dễ test hơn.

Khi mà chạy hàm foo() và console.log(a); nhưng không tìm thấy variable a trong scope của foo, javascript engine sẽ tìm outer scope (hay parent scope), tức là scope mà bao cái scope foo. Ở đây, parent scope của foo chính là global scope, ở đây biến a được khai báo là var a = 'Ahihi' nên hàm console.log(a); sẽ cho ra kết quả là Ahihi.

Lý do mà parent scope của foo là global scope chứ không phải scope mà bar(); (mặc dù hàm foo() được gọi bên trong bar()) là do việc quyết định scope nằm ở lúc compile, chứ không phải lúc excute. Khi compile thì javascript engine chỉ quan tâm tới declaration, tức là, scope và parent scope của một function sẽ quyết định khi mà nó được khai báo (declaration).

Hàm foo() và bar() đều được khai báo, sao cho outer scope, hay parent scope của nó, là global. Nên bỏ phần khai bảo bên trong local scope của mỗi function đi thì giá trị a in ra sẽ là giá trị global var a = 'Ahihi';

@pht Cảm ơn anh đã hiểu câu hỏi của em và nêu ra những ví dụ khác liên quan để thấy vấn đề rõ ràng hơn.

Nhìn chung, em nghĩ đi dùng "hàng" của người khác thì phải chấp nhận làm theo hướng dẫn sử dụng của họ.

Thôi thì code cũ chạy ngon thì kệ nó, mình viết code mới thì tạo contract mới thôi. Không lại gặp trường hợp vào đọc container, rồi viết một class khác implements đúng interface, quay ra thấy "method not exist" thì mệt lắm.

Lỗi typo nhiều lắm ==

Bạn code gì trên notepad ? Bạn là font-end ?

@quynh001 Mình cũng không đồng tình với cách làm của Laravel.

Type hinting là contract mà lại sử dụng specific method trong concrete class thì rõ ràng là không hợp lý.

Theo mình contract sinh ra là để có thể custom, thay đổi implement dễ dàng và chỉ cần refer đến contract. Chẳng lẽ đã có contract rồi lại phải tìm trong concrete class xem có method nào khác để implement?

Simplicity

When all of Laravel's services are neatly defined within simple interfaces, it is very easy to determine the functionality offered by a given service. The contracts serve as succinct documentation to the framework's features.

In addition, when you depend on simple interfaces, your code is easier to understand and maintain. Rather than tracking down which methods are available to you within a large, complicated class, you can refer to a simple, clean interface.

Cũng có nhiều issue về vấn đề này nhưng có issue được fix, có issue thì không, và vẫn chưa có câu trả lời nào xác đáng cả

• https://github.com/laravel/framework/issues/18361
• https://github.com/laravel/framework/issues/18792
• https://github.com/laravel/framework/issues/20472
• https://github.com/laravel/framework/issues/11200

Trong pull này ông GrahamCampbell có trả lời:

I understand what you are saying that this is technically incorrect without the method on the interface. I understand that just fine, but, this is not the only place where this occurs, and Taylor intentionally missed out some methods.

Có vẻ như có quá nhiều chỗ đã dùng theo cách này, giờ nếu thêm method vào interface có thể gây ra breaking changes nên họ quyết định là won't fix

Còn đoạn này thì mình không hiểu lắm: Taylor cố tình bỏ qua một số method??

Taylor intentionally missed out some methods

Có khi bạn hỏi ông Taylor phát cho a e thông suốt được không

Mình là một người vô cùng thích code trên notepad. và mình tin rằng cũng có rất nhiều người giống như mình.

Kỹ như này mà chẳng ai like ). Mình vote cách đầu dù làm cho ai đi nữa. Vừa học được, về lâu dài tốt hơn.

Mình cũng ít code trên notepad ++ chỉ thỉnh thoảng sửa cái gì đó nhỏ lẻ và đơn giản thì mới mở notepad++ lên sửa 1 xíu cho nhanh. Chứ nếu mình thường xuyên dùng notepad++ hoặc bất cứ editor nào không có sẵn tính nắng format code thì mình cũng sẽ cài thêm plugin cho nó để sử dụng.

Những editor như notepad++ không có sẵn tính năng này đâu bạn .

mà mình còn chưa hiểu chỗ API khi xây dựng 1 SPA : " Ứng dụng của bạn phải phát hành một API cho các client khác (nội bộ hoặc công khai). "

bạn có thể giải thích cho mình API là gì và sao làm SPA lại phải có API được không ?

cám ơn bạn, bài viết hữu ích với mình

Hình ảnh của mình đã được lưu trong database với dạng <img src="..."></img> Có cách nào để convert cái đó qua dạng lazy như bạn chia sẻ bên trên không nhỉ? <img class="lazy" src="data:image/png;base64,R0lGODlhAQABAAD/ACwAAAAAAQABAAACADs=" data-original="img/example.jpg" width="640" height="480">

Bài viết liệu có quá sơ sài khi chỉ nói về một phần của monkey patching :-?

(khoc)

Hiếu ơi về Div 1 đi

Host thứ 6 nên k đi được vì đi làm. Chắc có nhiều anh em giống mình

Có cảm giác như bạn dùng google dịch thì phải. Nếu dịch những bài kiểu như này làm cho người đọc dễ loạn thêm.